tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bullock <>
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 00:29:03 GMT
Hi Bob,

> 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.

I'd have thought that where an interface doesn't declare that it is
threadsafe, one cannot assume that it will be.  Further, if a
RemoteEndpoint represents 'the peer of a web socket conversation',
then a RemoteEndpoint, like a conversation, can surely support only a
single 'conversation state'?

IMHO, the correct choice is for each thread to have its own
RemoteEndpoint.  If the protocol being used happens to multiplex
multiple conversations to/from different endpoints over the same
TCP/UDP socket (for example), then the plumbing will do the
appropriate synchronization at that point - there would be no
advantage (and possibly some big disadvantages) for you to do your own
synchronization.  Critically, a RemoteEndpoint does not necessarily
represent a 'heavyweight' object like a Socket, and you should not be
at pains to manage your own pool of them, nor necessarily (unless it
made sense for application logic) to have a queue of messages which is
dispatched from a single thread.

However, I do think that many JSR's which ought to know better are
very lame about thread-safety guarantees for application authors, and
that more needs to be said in API documentation about patterns for
concurrent usage.  I encourage you to lobby your particular JSR of use
to include this information in future releases of the specification.
I did my bit recently at

David Bullock

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

View raw message