> -----Original Message----- > From: Niki Dokovski [mailto:nick...@gmail.com] > Sent: Tuesday, October 22, 2013 1:11 AM > To: Tomcat Users List > Subject: Re: is the Tomcat-7 WsRemoteEndpointImplBase send methods > threadsafe, or should we be synchronizing until the Future<>.get() returns? > > On Tue, Oct 22, 2013 at 3:29 AM, David Bullock < > david.bull...@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 >
Thank you, Niki, for the spec clarification bob > > > > > 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-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
