On 23/10/2013 14:09, Konstantin Preißer wrote: >> 1) How to asynchronously close / abort a Websocket session?
async close would require an API change. abort also requires an API change. Both look fairly easy to implement on the face of it. I'd suggest raising an enhancement request for the WebSocket JSR and then we can consider a Tomcat specific extension to WsSession to implement it until the spec catches up. We can probably agree some standard method signature amongst the implementations (or at least a few of them) on the WebSocket EG list first which should ease the migration pain. >> 2) It seems that when using RemoteEndpoint.Basic to send data >> synchronously and the remote endpoint does not read from the TCP >> connection, then a TimeoutException (wrapped in IOException) is thrown >> several seconds after calling send(). However, when using >> RemoteEndpoint.Async to send data asynchronously, this is not the case - >> the SendHandler is not called until the remote endpoint continues to read >> data. Is there some configuration to set a Timeout for async sending? RemoteEndpoint.Async.setSendTimeout() The problem is that the spec doesn't define a timeout for blcoking IO hence why Tomcat has the org.apache.tomcat.websocket.BLOCKING_SEND_TIMEOUT user property for the session. >> 3) It seems that session.close() will call the onClose method of the >> Endpoint, >> even if this was called inside of another event handling method like >> onMessage. Why shouldn't it? Why is this a problem? > 4) Tomcat's current implementation of RemoteEndpoint.Async#sendText(String, > SendHandler) can cause StackOverflowErrors (and seems to contradict Oracle's > JavaDoc). That is a bug. Although changing it is only going to make things slower. > 5) Thread safety for Endpoint > > The javadoc of class javax.websocket.Endpoint says: > > "Each instance of a websocket endpoint is guaranteed not to be called by more > than one thread at a time per active connection. " > > As I'm not a native english speaker, I'm not sure if I understand exactly > what this means. By default there is one endpoint instance per connection. In this case there will only ever be one container thread accessing the Endpoint at any one time. However, you can configure things so an endpoint serves multiple connections (much like a Servlet does). In this case there may well be multiple threads accessing the endpoint at the same time but each thread will be associated with the connection for a different client. Containers are free to recycle container objects such as sessions if they wish. It would be foolish in the extreme for a container to try and recycle a application provided object (such as an Endpoint instance) as there is no API for the container to use to recycle the object. HTH, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
