Joakim, I can't see that RemoteEndPoint#sendString can throw a
WebSocketException.
It declares that it throws IOException, but if I drill down through the
implementation I can't find anywhere that WebSocketException might be
thrown.
Are you sure it might do that?

NB the unchecked WebSocketException thrown by WebSocketAdapter#getRemote
caught me unawares since it's not mentioned in the Javadoc

William

ᐧ

On Tue, May 19, 2015 at 5:28 AM, Joakim Erdfelt <[email protected]> wrote:

> Being multi-threaded, this wouldn't solve your problem.
>
> Even if Session.getRemote() returned null for an invalid Remote due to
> closing/closed state change, there's still a window of time where you can
> get a Remote, but the connection can close before you can use the Remote.
>
> You'd still need to check for WebSocketException either in the blocking
> .send() method call, or via the Future.get(), or via the WriteCallback.
>
> Another common usage/pattern is to grab a reference to the Remote in the
> onOpen/onConnect and continue to use it for the lifetime of the
> connection.  Those using remote in this way wouldn't benefit from this sort
> of change.
>
>
> --
> Joakim Erdfelt <[email protected]>
> webtide.com <http://www.webtide.com/> - eclipse.org/jetty - cometd.org
> Expert advice, services and support from from the Jetty & CometD experts
>
> On Fri, May 15, 2015 at 11:26 PM, William Ferguson <
> [email protected]> wrote:
>
>> Woops - forgot to provide version. This is on Jetty-9.2.10
>>
>>
>> ᐧ
>>
>> On Fri, May 15, 2015 at 5:44 PM, William Ferguson <
>> [email protected]> wrote:
>>
>>> First, thanks so much for such a fantastic product.
>>> Jetty has been my go to web server for a *really* long time now and it
>>> never disappoints.
>>>
>>> I have recently created a web app that uses WebSockets as the primary
>>> communication with its clients and it all works well. But we occasionally
>>> get the following WebSocketException
>>>
>>> org.eclipse.jetty.websocket.api.WebSocketException: RemoteEndpoint
>>> unavailable, current state [CLOSING], expecting [OPEN or CONNECTED]
>>> at
>>> org.eclipse.jetty.websocket.common.WebSocketSession.getRemote(WebSocketSession.java:252)
>>> at au.com.xandar.obfuscated.cm.a(SourceFile:41)
>>>
>>> when we are in the middle of processing an incoming request and attempt
>>> to get the remote endpoint in order to send a message back.
>>>
>>> We have tried to mitigate by checking Session#isOpen but it uses a
>>> different condition to determine whether the Session is open than what
>>> #getRemote does, and it would also suffer from a potential race condition.
>>>
>>> Other than catching the unchecked WebSocketException on #getRemote
>>> (which seems wrong) is there a definitive way to determine whether I can
>>> send to the client?
>>> Wouldn't it perhaps be better if #getRemote returned null if the remote
>>> end point was no longer available?
>>>
>>>
>>> William
>>>
>>> ᐧ
>>>
>>
>>
>> _______________________________________________
>> jetty-users mailing list
>> [email protected]
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>
>
> _______________________________________________
> jetty-users mailing list
> [email protected]
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
_______________________________________________
jetty-users mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

Reply via email to