tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: http request (no only session) replication in cluster
Date Tue, 11 Jun 2013 19:57:22 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

André,

On 6/11/13 11:32 AM, André Warnier wrote:
> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> Ja,
>> 
>> On 6/11/13 9:54 AM, Ja kub wrote:
>>> What can be done to guarantee failover in below scenario:
>>> 
>>> 2 tomcats behind cisco loadbalancer 1 http request can last
>>> very long about 50 seconds - response from webservice can take
>>> so long load is 200 requests per second I must response in max
>>> 4 seconds more than backing webservice
>>> 
>>> is there something like http request replication ?
>>> 
>>> 50 s * 200 req/s = 10.000 pending requests
>>> 
>>> if one tomcat is eg killed, can in any way other tomcat serve
>>> his requests ?
>>> 
>>> is there any out of the box solution, eg similar to session 
>>> replication ?
>> 
>> The best way to do this is to configure your load balancer to
>> buffer responses and re-try another cluster node in the case of
>> an unexpected disconnect.
>> 
>> If you can't buffer the response, then it is entirely
>> inappropriate to re-process a request: instead, you should let
>> the failure propagate all the way back to the client and let them
>> decide what to do.
>> 
>>> is it possible to save socket to database, or send it via
>>> network?
>> 
>> No. I think you are confused about what a socket is.
>> 
> 
> Is that just me, or does this look like a *massive* imbalance
> between the load, and the resources dedicated to serve that load ?

+1

200 req/sec * 50 seconds per request?

I get some folks do high-volume, high-response-time transactions.
Thankfully, not I ;)

> I somehow have trouble to envision any system working in any stable
> way, when right from the start it is assumed to have 10,000
> requests simultaneously being in various stages of processing.
> Unless one would have some Google-like server farms behind the
> thing anyway.

10k concurrent requests isn't really that insane. It's just having
them for nearly a minute each that's quite extraordinary.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRt4EhAAoJEBzwKT+lPKRY/+oQAI+BlbCJ7i7DzRYD2PnQfGYH
KXPTcXg7iYaiQtzP+jZBtKa9+EAkS2Kad+5fUyY8/rd81yxgRNVJ7N2EbNlOAJNM
9zbeAszl5+3tEUOuqktcibtuwdMjC4U0XcmyThBjFy1LAvggvoGOaZvVyLQleyps
Lw6fdUh0gy4fvkfSCEwZb1BQRbF8qO8bpqfaR7WorOgAcXEQMp5d0iiUwBydJLYQ
hFraOXvmDfNl6lbODoW0Wtd9YQKmj/sMCG86Tm9BVVUmOgL5df9Pbgac1FzDAMpP
/llROIH+T/8aT4u+iSByKcqmpAB6qI/csRk09vn3O6ZfffrmPGTKT1XfcN8iU6bn
b9nRTVah+pES6eHlOVMgFJ2hZ8uYSTETteZZAMUr24oH6TTvHDj7CYXfFioLQjI9
elvKvMpgU+JDpOfEX8ly/+u0GmMJH4WXT1EjL9l4JEMZuQyvWCgzwfC0JyqS0vVq
hGCOZlLWhwDyEZ9atESKasuRamexYUMqgMQimXhWNzI+ruP4NU050M3n1bM+vl7J
r1qzMCgcxD3jOvhoACQmfJ3APeoEfVKn2vc5ypzjGkS2fCK3rTmCnsEAl4R0JzBu
zYVWTCqFPZlgKaqEb+xlzdoi7CwEDRHc12CblYAQBIXkEW4c9fI929wuQPsuI3yp
bVZBgYBAeckMEr03ay+Y
=30OJ
-----END PGP SIGNATURE-----

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


Mime
View raw message