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

Reply via email to