On 28/10/2013 13:49, Konstantin Preißer wrote: > 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.
If you haven't already, can you create a Bugzilla entry for this so it doesn't get forgotten. Thanks, Mark > > >>> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
