tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Preißer <kpreis...@apache.org>
Subject RE: Some Websocket (Async) questions
Date Mon, 28 Oct 2013 13:49:23 GMT
Hi Mark,

thanks a lot for your reply.

> -----Original Message-----
> From: Mark Thomas [mailto:markt@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message