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