Tomcat 8 JSR 356 WebSocket Threading -
i'm using jsr-356 websocket support in tomcat 8 drive application i'm working on. far, looks messages handled in single thread. while understand reasoning behind - , why websockets implemented way, there way use executorservice
handling message comes in (without creating executorservice in code)?
this allow scalability of having 1 (or few) network selector threads (to support large number of connected clients), while allowing standard thread-based processing of actual message (when message needs processed client).
i don't see in particular allow changed.
the threading model varies depending on connector using. scalability want use nio (the default) or apr/native (buggy of 8.0.0-rc3). nio choice @ moment. apr/native issues should fixed shortly (i working on when saw question).
nio uses selector , thread pool handle received messages. when selector detects data available passes socket thread thread pool (via executor) process it. processing may result in data being buffered internally, application being notified of partial message, application being notified of complete message or combination of these. notification application handled same thread processes incoming data.
if multiple messages received multiple clients multiple threads dispatched handle messages.
there no functionality in jsr 356 api allow application opt messages or partial messages handled via executorservice 1 application has been notified of new message without application implementing one. should relatively simple application handles whole messages implement this. if applications handles partial messages lot harder.
apr/native (once fixed) behave same way nio. bio uses blocking io (even jsr356 api indicates non-blocking) , requires 1 thread per connected client rather 1 thread per connected client data process.
Comments
Post a Comment