tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
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 [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.

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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message