tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Grigorov <>
Subject Re: websockets questions
Date Thu, 04 Jul 2013 09:22:37 GMT
Hi Andre,

On Thu, Jul 4, 2013 at 12:17 PM, André Warnier <> wrote:

> I'll just add a little bit of info (and guesses) below.
> Jess Holle wrote:
>> Unfortunately I don't have any information -- just related questions.
>> 1. For someone currently using Apache httpd+mod_jk to load balance
>>    requests, what does one do about load balancing WebSockets requests
>>    between Tomcat instances?
>>      * As Andre alluded to, the only mention of websocket handling in
>>        Apache httpd really appears to be in its infancy.
>>      * It would kind of seem like mod_jk should be expanded to deal
>>        with WebSockets...
>>      * In any case, there would still be questions as to how this
>>        interacts with mod_jk within the same web app.
>> 2. Any other browser considerations beyond requiring IE 10+? Are
>>    relatively recent Chrome, Firefox, and Safari WebSocket ready?
>  3. How well do WebSockets play with existing network infrastructure?
>>      * IP load balancers
>>      * HTTP(S) forward and reverse proxy servers
>>      * Timeouts (idle, response, etc...)
>>    In general, if WebSockets don't just "get along with" existing
>>    network infrastructure in this regard but rather place requirements
>>    and restrictions upon it to function properly, then it will be a
>>    while before those of us who need to deploy a single solution into
>>    many disparate environments can leverage WebSockets in any
>>    substantive fashion.
> The way I understand websockets is :
> - it starts with a "normal" HTTP request from client to server.  In that
> HTTP request, there is a header requesting an "upgrade" of the
> (theoretically one-off fire-and-forget) HTTP connection, to a websocket
> connection
> - if the server supports it, it does "set aside" the existing TCP
> connection (client-server), to be from now managed as a permanent
> client-server connection, and it lets the client know about this.
> From then on, the client and server have a permanent TCP connection, on
> which they can exchange "websocket messages" back and forth, until they
> agree that they are done, and drop the connection.
> 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).

AFAIK when using BIO socket this is the case.
But when using NIO (and AJP?!) Tomcat uses different threads per data frame.

> For that same reason, it would seem that the very concept of
> "load-balancing" must be suspended once the websocket connection is
> established.
> If there is a front-end between the client and the server (which actually
> runs the application that "converses" with the client over the websocket),
> then at the level of this front-end that connection must be like some kind
> of "tunnel", which merely passes packets back and forth between the client
> and the back-end websocket-enabled application.
> That's a bit what the Apache httpd mod_proxy_(websocket) (not sure of the
> name anymore) sounds like.
> I have seen Rainer involved in that mod_proxy_(websocket) discussion, and
> since Rainer is one of the mod_jk developers, I would think that there must
> be some link with mod_jk. Which would make some sense, because if a browser
> connects to Tomcat through Apache httpd and mod_jk, and then requests an
> upgrade to websockets, mod_jk must be able to at least know that what is
> going to pass further on that connection is not HTTP-like anymore.
> But that's about all I've been able to sniff and guess so far.
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**<>
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message