Dontpush ozonelayer - Stackoverflow


I have replaced the icepush by dont push ozone in redVoodo. Therefore i had to create some bundles based on the current versions. Took some time, but now the application is running really fast based on dontpush ozone.

It works really fine if i am using the
?debug parameter
But if i try to start the server without it, i am getting an StackOverflowError exception. See below.

I am using jetty 8.1.0.RC1.

May it be some kind of timing problem? The “debug”-parameter will
slow down the client
, sure?

Are there any known issues?
Thanks a lot for any kind of hint!

Florian Pirchner

SLF4J: Failed toString() invocation on an object of type [org.eclipse.jetty.websocket.WebSocketConnectionD13]

at java.util.concurrent.ConcurrentHashMap.get(
at sun.util.LocaleServiceProviderPool.getPool(
at java.text.DecimalFormatSymbols.getInstance(
at java.util.Formatter.setZero(
at java.util.Formatter.init(
at java.util.Formatter.(
at java.lang.String.format(
at java.lang.String.valueOf(
at java.lang.StringBuilder.append(
at org.eclipse.jetty.websocket.WebSocketConnectionD13.toString(
at java.util.Formatter$FormatSpecifier.printString(
at java.util.Formatter$FormatSpecifier.print(
at java.util.Formatter.format(
at java.util.Formatter.format(
at java.lang.String.format(


I haven’t seen such an issue. Would you try with latest Jetty (Stable 8.1.2.v20120308)? If it is reproducible there as well, we need to check what is going on.


Hi Matti,

did some debug sessions and could find the bug. The StackOverflow is produced by a log statement.


Then i tried the stable 8.1.0 and the bug does not appear again! :wink:
Now i am going to thest the stable 8.1.2

Websockets in combination to vaadin is super incredible fast.


Stable 8.1.2.v20120308 works fine. Not bugs found yet!

Well, I currently have a weird issue with dontpush ozone… seems to be a timing thing.

the app is at:

When I developed it and tested it in my PC/LAN, everything worked fine. I could connect two browsers (Chrome and a Chrome_Incognito, or Chrome and iExplorer, or Chrome and a BlackBerry PlayBook) and both would connect to the App and use “push” features (which includes pretty much everything in the app, for it is a two player game, witch chat included).

I was so happy with it… it’s so fast. When the “other player” clicks something, I immediately see what he did in MY window.

for it to work I had to synchronize code that modifies a session’s window’s contents on “other threads” (threads other than servlet requests for the correct session) with synchronyze(application) { … }

it all worked beautifuly… until I tried to deploy it on amazon AWS. Now it behaves so weird: at first, the push stuff works (when the only threads involved are the servlet request threads), but when a third “background” thread is launched (one that will account for timeouts and other stuff)… the push stuff ceases to work for Chrome and PlayBook… yet keeps working for InternetExplorer 8.

when hosted on AmazonAWS, things only work for Internet Explorer 8. the app freezes on Chrome and webkit, in those a “loading” indicator appears on the top right corner of the browser content, changing colors from yellow to red, and the ?debug window shows in it’s last line the error: “JavaScriptException: (SyntaxError): Unexpected token ILLEGAL”

It doesnt seem to make any difference whether I use ?debug or not.

I’m using jetty 8.1.2., Vaadin 6.7.1 and dont-push-ozone 0.3.11.
For now I’m assuming the problem must be a thread synchronization issue on my code… altough the fact it ALWAYS works on Internet Explorer 8 gives me kind of a bad feeling.
We’ll see.

I just wanted to tell you, that Don’tPush Ozone can be a bit tricky.



I am using jetty 8.1.2, vaadin-6.7.7.nightly-20120314-c23232 and dontpush-addon-ozonelayer-0.4.3-SNAPSHOT.

So far the problem did not occur again.


All concurrency stuff, in all programming environments, especially when there is network involved. Still, just synchronizing over app being modified should get you over most issues.

Quickly looking at your app it seems to me that you are not using the latest release. Atmosphere has a limit of 8kb message size by default (when web sockets are used), so if you are making big UI changes at once you client side might die. The latest release overcomes this by splitting messages on the server side and combining them again in the client. I’m quite sure upgrade will help you here.


See for tips on using Atmosphere in EC2.