On 17/06/2023 16:54, Nikolai Zhubr wrote:
Hi,
On 6/14/23 19:43, Mark Thomas wrote:
[...]
There is no multi-threading within a single WebSocket connection. It
is explicitly not allowed by the Jakarta WebSocket specification and
Tomcat follows that rule.
Could you please point out where such guarantee is implemented exactly?
I'll turn that around. Can you point to a code path where that
specification required guarantee isn't honored? Hint: work your way up
the call stack and the answer will be obvious.
From what I can see in 9.0.36 source code the call chain down to
onMessage is apparently as follows:
WsFrameServer.notifyDataAvailable()
--> WsFrameServer.doOnDataAvailable()
--> WsFrameServer.onDataAvailable()
--> WsFrameBase.processInputBuffer()
--> WsFrameBase.processData()
--> WsFrameBase.processDataBinary()
--> WsFrameBase.sendMessageBinary(...)
--> binaryMsgHandler.onMessage(...)
In notifyDataAvailable one can see some
changeReadState(ReadState.WAITING, ReadState.PROCESSING) before calling
onDataAvailable() and changeReadState(ReadState.PROCESSING,
ReadState.WAITING) after. Is it the thing that is supposed to protect
against concurrent (and/or out-of-order) calling of onMessage?
Tomcat is open source. That means you can look at the commit history and
(hopefully) find out why code was added. GitHub even provide a nice web
GUI allowing you to step back through multiple changes one at a time.
If you want to find out what that code does, start here:
https://github.com/apache/tomcat/blame/main/java/org/apache/tomcat/websocket/server/WsFrameServer.java#L159
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
