tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: is the Tomcat-7 WsRemoteEndpointImplBase send methods threadsafe, or should we be synchronizing until the Future<>.get() returns?
Date Tue, 22 Oct 2013 07:31:58 GMT
On 22/10/2013 00:28, Bob DeRemer wrote:
> I'm trying to understand how Tomcat's outbound message processing
> works with respect to making multiple (concurrent) calls against a
> single RemoteEndpoint.Async using sendText/sendObject.  Based on the
> ExecutionExceptions we got (see below), it seems that we should
> probably synchronize sends until the Future<>.get() returns, but I
> want to check with the community to be sure.  I tried searching the
> javadocs of RemoteEndpoint.Async and associated interfaces, but could
> not find anything describing the threadsafe nature (existing or not).
> It appears that the spec lets the implementation determine how to
> handle stuff under the covers.  This is fine, but we just need to
> understand what that means to multi-threaded code that wants to send
> messages.

There was some discussion [1] in the EG on this point and the conclusion
was that the previous message had to complete before the next message
was sent. If you batching is used (which Tomcat supports) the semantics
for complete change but the previous message still has to complete
before the next is sent.

I've looked through the specification and I don't see this made clear
anywhere. My experience of the J2EE EG's is that in cases like these
following the intention of the EG based on the mailing list archive is
the way to go.

> Looking at the Tomcat code, it looks like WsRemoteEndpointImplBase
> uses a static SendHandler (i.e. TextMessageSendHandler).

That is a static definition of a class, not a static instance. A new
instance is created for each message.

> I noticed a
> little further down in the stack the logic does synchronize around a
> messagePartQueue, but this seems to be for handling parts of a single
> message.

Correct. That is to ensure correct state management when different
threads are sending different parts of the message.

> Otherwise, it looks like it doesn't expect another message
> to be sent until it's finished writing out.

Correct. It should throw an exception if you try.

> ExecutionException: In some recent testing of our client/server
> Endpoint(s) (using a locally built instance of Tomcat 7.0.48), we got
> ExecutionExceptions when sending messages concurrently without any
> delay.  The errors started with a few Null Ptr(s), then were all
> wsRemoteEndpoint.inProgress (Message will not be sent because the
> WebSocket session is currently sending another message)
> Is my understanding correct, or am I missing something?  Thanks in
> advance for any clarification.




To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message