tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob DeRemer <bob.dere...@thingworx.com>
Subject is the Tomcat-7 WsRemoteEndpointImplBase send methods threadsafe, or should we be synchronizing until the Future<>.get() returns?
Date Mon, 21 Oct 2013 23:28:22 GMT
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.

Looking at the Tomcat code, it looks like WsRemoteEndpointImplBase uses a static SendHandler
(i.e. TextMessageSendHandler).  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.  Otherwise, it looks like it doesn't expect another message to be sent until it's
finished writing out.

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.


Thanks,

Bob DeRemer
http://www.thingworx.com<http://www.thingworx.com/>
Skype: bob.deremer.thingworx


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message