tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niki Dokovski <nick...@gmail.com>
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 05:10:42 GMT
On Tue, Oct 22, 2013 at 3:29 AM, David Bullock <
david.bullock@machaira.com.au> wrote:

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

JSR 356 Specification Section 5.1 Threading Consideration discusses the
topic.
In particular;
[WSC-5.1-2] - "the implementation must not invoke an endpoint instance with
more than one thread per peer at a time."
[WSC-5.1-4] - "a websocket endpoint instance is never called by more than
one container thread at a time per peer."

cheers


>
> 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 https://java.net/jira/browse/SERVLET_SPEC-81
>
> cheers,
> David Bullock
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

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