tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Some Websocket (Async) questions
Date Mon, 28 Oct 2013 14:26:10 GMT
On 28/10/2013 13:49, Konstantin Preißer wrote:
> Hi Mark,
> thanks a lot for your reply.
>> -----Original Message-----
>> From: Mark Thomas []
>> 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:
>>>> 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.



>>> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message