Discussion:
[jetty-users] Server-side WebSocket frame ordering
coudy
2018-01-10 23:48:18 UTC
Permalink
I'm trying to process WS frames in incoming order per socket and am a bit
stuck.

My `@OnWebSocketMessage` handler gets dispatched on various threads out of
the Jetty server thread pool, which seems to be used for all manner of
things, so I can't simply configure that to have one thread.

As such it doesn't look like per-socket (per-session) threading is
configurable. Since messaging ordering in WS is obviously derived from TCP's
the lack of configurability is extremely surprising. I hope I'm just missing
something.

Many thanks for any pointers.



--
Sent from: http://jetty.4.x6.nabble.com/Jetty-User-f3247280.html
Joakim Erdfelt
2018-01-10 23:57:56 UTC
Permalink
@OnWebSocketMessage is a Jetty API for whole message delivery of websocket
messages.

The internals of Jetty will aggregate the individual frames and then call
your method with the entire message.

For WebSocket frames access, don't use annotations, and instead use the
org.eclipse.jetty.websocket.api.WebSocketFrameListener.
http://download.eclipse.org/jetty/stable-9/apidocs/org/eclipse/jetty/websocket/api/WebSocketFrameListener.html

The only scenario where @OnWebSocketMessage method will be called from
different threads is if you are using a streaming based approach to
handling.
For each websocket message, the first frame will result in a dispatched
@OnWebSocketMessage to you.
Each dispatch will be on a new thread, this is to allow your websocket
application the opportunity to read the websocket message via the java.io
Stream APIs.
When the message is finished (fin=true frame received), then the final
payload is delivered to your prior dispatched thread and a new message is
allowed to be started.

To avoid this dispatch, use String (for websocket TEXT messages) or
ByteBuffer (for websocket BINARY messages) object types in your
@OnWebSocketMessage method, not streams.
Those are delivered to your application's @OnWebSocketMessage in the same
thread as the one managing the reads operations from the internal websocket
connection.
Post by coudy
I'm trying to process WS frames in incoming order per socket and am a bit
stuck.
the Jetty server thread pool, which seems to be used for all manner of
things, so I can't simply configure that to have one thread.
As such it doesn't look like per-socket (per-session) threading is
configurable. Since messaging ordering in WS is obviously derived from TCP's
the lack of configurability is extremely surprising. I hope I'm just missing
something.
Many thanks for any pointers.
--
Sent from: http://jetty.4.x6.nabble.com/Jetty-User-f3247280.html
_______________________________________________
jetty-users mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Michal Čudrnák
2018-01-11 00:50:28 UTC
Permalink
Joakim, that's a really good explanation, everything makes sense now. Yes,
I'm using streaming for both text and binary messages. FYI, I mentioned
frames but really meant messages, I don't do any fragmentation in my
protocol anyway.
Post by Joakim Erdfelt
@OnWebSocketMessage is a Jetty API for whole message delivery of websocket
messages.
The internals of Jetty will aggregate the individual frames and then call
your method with the entire message.
For WebSocket frames access, don't use annotations, and instead use the
org.eclipse.jetty.websocket.api.WebSocketFrameListener.
http://download.eclipse.org/jetty/stable-9/apidocs/org/eclipse/jetty/websocket/api/WebSocketFrameListener.html
different threads is if you are using a streaming based approach to
handling.
For each websocket message, the first frame will result in a dispatched
@OnWebSocketMessage to you.
Each dispatch will be on a new thread, this is to allow your websocket
application the opportunity to read the websocket message via the java.io
Stream APIs.
When the message is finished (fin=true frame received), then the final
payload is delivered to your prior dispatched thread and a new message is
allowed to be started.
To avoid this dispatch, use String (for websocket TEXT messages) or
ByteBuffer (for websocket BINARY messages) object types in your
@OnWebSocketMessage method, not streams.
thread as the one managing the reads operations from the internal websocket
connection.
Post by coudy
I'm trying to process WS frames in incoming order per socket and am a bit
stuck.
the Jetty server thread pool, which seems to be used for all manner of
things, so I can't simply configure that to have one thread.
As such it doesn't look like per-socket (per-session) threading is
configurable. Since messaging ordering in WS is obviously derived from TCP's
the lack of configurability is extremely surprising. I hope I'm just missing
something.
Many thanks for any pointers.
--
Sent from: http://jetty.4.x6.nabble.com/Jetty-User-f3247280.html
_______________________________________________
jetty-users mailing list
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
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Simone Bordet
2018-01-11 00:03:42 UTC
Permalink
Hi,
Post by coudy
As such it doesn't look like per-socket (per-session) threading is
configurable.
I'm interested in knowing why would that be desirable for you ?
--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Michal Čudrnák
2018-01-11 00:54:58 UTC
Permalink
I'm specifically interested in processing messages in incoming order. There
are several reasons I can think of to do with managing state associated
with the socket, e.g. in my protocol you send an authentication message,
which doesn't require a response, followed by request that relies on said
authentication.
Post by Simone Bordet
Hi,
Post by coudy
As such it doesn't look like per-socket (per-session) threading is
configurable.
I'm interested in knowing why would that be desirable for you ?
--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-users mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Loading...