tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Pospisil <dposp...@redhat.com>
Subject Re: mod_jk maintenance, recovery
Date Mon, 21 Jan 2008 14:32:54 GMT
Rainer,
thanks for valuable info.

>> Let's see, if this matches your experience: assuming recovery_options=0,
> the request should be retried on other lb member workers (if such exist
> and are OK), unless it's a POST and the POST body is bigger than 8186
> bytes and more than the first 8186 bytes have already been sent to the
> backend.
>
> Why doesn't it get retried in this case? Because we only buffer that
> many data for retry.
>
> POST bodies can get very big (uploads), so it's not good to buffer
> complete POST bodies (could take a lot of memory). AJP tries to stream
> packets through the web server to the backend as they arrive. The actual
> design simply decides to buffer one ajp packet, which is 8192 bytes
> minus ajp head = 8186 bytes.
>
> Does that fit your observations?
>

No, it does not. I am sending GET requests only. And again, errors are 
returned for couple of first request only - i am using 4000 clients and about 
100 clients receives this error. Than the second node switches from ERR/REC 
to OK state and rest of clients are redirected correctly.

>... adding to previous post:
>
>It also does not retry/fail over, in the following (more or less obvious 
>cases):
>
>- there was a problem with the client (browser) connection
>- we already started to send back parts of the response to the client, 
>typically the headers (depending on recovery_options; default: 
>retry/fail over)
>- Internal JK error (not observed in practise yet)
>- depending on recovery_options: if the backend received the request 
>(default: retry/fail over)

None of this options seems to be the case too. If some data were send back to 
client before failover, i would detect it in the load generator.


mod_jk.log fragments:

couple of first lines after failover:
[Mon Jan 21 08:47:26 2008][27428:1262557536] [error] 
ajp_send_request::jk_ajp_common.c (1359): (cluster01) connecting to backend 
failed. Tomcat is probably not started or is listening on the wrong port 
(errno=110)
[Mon Jan 21 08:47:26 2008][22609:1252067680] [error] 
ajp_send_request::jk_ajp_common.c (1359): (cluster01) connecting to backend 
failed. Tomcat is probably not started or is listening on the wrong port 
(errno=110)
[Mon Jan 21 08:47:26 2008][29495:1115699552] [error] 
ajp_send_request::jk_ajp_common.c (1359): (cluster01) connecting to backend 
failed. Tomcat is probably not started or is listening on the wrong port 
(errno=110)

...
[Mon Jan 21 08:48:40 2008][20105:1335986528] [error] 
ajp_get_reply::jk_ajp_common.c (1766): (cluster01) Tomcat is down or refused 
connection. No response has been sent to the client (yet)
[Mon Jan 21 08:48:40 2008][20629:1157658976] [error] 
ajp_get_reply::jk_ajp_common.c (1766): (cluster01) Tomcat is down or refused 
connection. No response has been sent to the client (yet)

There is absolutelly no indication, that mod_jk is unsuccessfuly trying to 
connect cluster02 at this point, there are no errors related to cluster02 
(except couple of requests at the beginning of the tests).

Thanks,

Dominik

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


Mime
View raw message