Konstantin,
> Right, I also think the calls to getBasicRemote().sendText(...) should > be synchronized as multiple threads can concurrently access this method for > a particular client (that however could mean that if one client stops > receiving from its WebSocket connection, no other client can receive > messages - to solve this, e.g. one could use a dedicated thread for each > client which takes and sends messages from a queue, or use the > RemoteEndpoint.Async). > Oracle's javadoc of RemoteEndpoint.Basic says: > > "If the websocket connection underlying this RemoteEndpoint is busy > sending a message when a call is made to send another one, for example if > two threads attempt to call a send method concurrently, or if a developer > attempts to send a new message while in the middle of sending an existing > one, the send method called while the connection is already busy may throw > an IllegalStateException." > ah ok, that makes sense then, i still would say why not make sendText of BasicRemote a synchronized method inside tomcat. Because that is what it really needs to be anyway, but doing a sync around that is fine in our code. But mistakes in this area are easily made, see for example the chat example. That one is not really thread safe, i guess the private static void broadcast(String msg) method should really sync around the connections field. And then i guess that connections doesn't have to be a copyonwritelist (also sync on it when changes to that list are made) What i still don't understand then when, had exactly the same code and instead of getBasicRemote() i do getAsyncRemote() that i also did get the same problems A sync in my code wouldn't fix that at all, because the method returns right away.. So i guess this has to be fixed by tomcat itself? So that asyncremote does take care of of the synchronization? > However, even after adding synchronization, I get stability issues and > several exceptions on current Tomcat 8 trunk when sending large messages. I > have filed a report here (I don't know if these are the same issues that > you got): https://issues.apache.org/bugzilla/show_bug.cgi?id=55799 > > > thats quite the same stuff, i only did get some other reported stuff inside the browser, i guess because of the scrambled data. I didn't really see that illegalstate exception showing up in the log. johan