Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Determining when WebSocketSession#getRemote is allowed

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 <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts

On Fri, May 15, 2015 at 11:26 PM, William Ferguson <william.ferguson@xxxxxxxxxxxxx> wrote:
Woops - forgot to provide version. This is on Jetty-9.2.10



On Fri, May 15, 2015 at 5:44 PM, William Ferguson <william.ferguson@xxxxxxxxxxxxx> 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
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


Back to the top