Hi Mark, thanks a lot for your reply.
> -----Original Message----- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Wednesday, October 23, 2013 8:58 PM > To: Tomcat Users List > Subject: Re: Some Websocket (Async) questions > > 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. OK, I have created an enhancement request here: https://java.net/jira/browse/WEBSOCKET_SPEC-216 > >> 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. OK, thanks. > >> 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? I don't think it is a problem - just wanted to confirm that this is intended behavior, as it may be a bit confusing to someone familiar with the JavaScript implementation, expecting that onClose() is only called after onMessage() returns. > > 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. Ok, thanks for the confirmation. > > 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. Thanks, that makes sense. Regards, Konstantin Preißer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
