On 04/07/2013 10:17, André Warnier wrote: > To me that means that at some point, there must be on the server side a > process or thread which is dedicated to this websocket client for as > long as it takes, and this process/thread in the meantime is no longer > available to process other HTTP requests. > (That's because the basic idea is that the "websocket application" on > the server side can keep sending messages asynchronously to the client - > and vice-versa - so I don't see how this can work with different > threads/processes on the server; but I'm not that smart, so it may be > that the implementation is smarter). > For that same reason, it would seem that the very concept of > "load-balancing" must be suspended once the websocket connection is > established.
The connection has to be kept open but you can use non-blocking IO to only allocate a thread to process data when there is data to process. The exact behaviour varies between Tomcat 7 and Tomcat 8. BIO 7 & 8 - 1 thread per connections, blocking IO, doesn't scale NIO / APR 7 - 1 thread per currently processed frame, non-blocking between frames, scales better NIO / APR 8 - threads only allocated where there is data to process, scales best Note that JSR356 allows blocking writes. If the client or the server opt to send data using a blocking write then that will use a thread until the write completes. Load-balancers should cope perfectly happily with this. There is no upgrade or WebSocket support in AJP yet. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
