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 Wed, 23 Oct 2013 18:58:03 GMT
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?


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

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



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

View raw message