On 17/06/2023 16:54, Nikolai Zhubr wrote:

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.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:



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

Reply via email to