You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mohit Anchlia <mo...@gmail.com> on 2010/03/31 23:09:28 UTC
mod_jk behaviour during failure
I am seeing weird behaviour here.
What I am seeing is that when server is not pingable (when I reboot
or shutdown) anymore mod_jk keeps logging errors 111 (connection
refused) and errors 115 continuously and during this timeperiod if I
look at "JkStatus" the State of the corresponding worker is still "OK"
(which is incorrect in this case since server is not pingable). During
this time period response times are still around 2-4 secs as compared
to 300 ms. When everything is good our requests take 300 ms.
Now once the server comes up (pingable) the state of the worker is
"ERR" and at this point everything returns back to normal. So it looks
like until server is pingable mod_jk doesn't put that worker in "ERR"
state. So my question is what can I do in worker.properties such that
worker goes in ERR state automatically when server or the machine
completely goes down? It's kind of odd that mod_jk doesn't put the
worker in ERR state when the box that worker is tied to is not
pingable?
---
worker.tc.type=lb
worker.tc.balance_workers=host1,host2,host3,host4,host5,host6
worker.tc.sticky_session=true
worker.host1.type=ajp13
worker.host1.port=8009
worker.host1.host=host
worker.host1.socket_keepalive=true
worker.host1.prepost_timeout=5000
worker.host1.connect_timeout=5000
worker.host1.retries=1
worker.host1.socket_connect_timeout=1000
worker.host1.connection_pool_minsize=0
worker.host1.connection_pool_timeout=20
worker.host1.recovery_options=7
worker.host1.ping_mode=A
worker.host1.ping_timeout=5000
...
[Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [info]
ajp_connect_to_endpoint::jk_ajp_common.c (922): Failed opening socket
to (10.10.81.153:8009) (errno=115)
[Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [error]
ajp_send_request::jk_ajp_common.c (1467): (host5) connecting to
backend failed. Tomcat is probably not started or is listening on the
wrong port (errno=115)
[Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [info]
ajp_service::jk_ajp_common.c (2407): (host5) sending request to tomcat
failed (recoverable), because of error during request sending
(attempt=1)
[Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [error]
ajp_service::jk_ajp_common.c (2426): (host5) connecting to tomcat
failed.
[Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [debug]
ajp_reset_endpoint::jk_ajp_common.c (743): (host5) resetting endpoint
with sd = 4294967295 (socket shutdown)
[Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [debug]
ajp_done::jk_ajp_common.c (2850): recycling connection pool slot=0 for
worker host5
[Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [info]
service::jk_lb_worker.c (1347): service failed, worker host5 is in
local error state
[Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [debug]
service::jk_lb_worker.c (1358): recoverable error... will try to
recover on other worker
[Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [debug]
get_most_suitable_worker::jk_lb_worker.c (969): found best worker
host6 (host6) using method 'Request'
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk behaviour during failure
Posted by Mohit Anchlia <mo...@gmail.com>.
On Sat, Apr 3, 2010 at 9:44 AM, Rainer Jung <ra...@kippdata.de> wrote:
> On 31.03.2010 23:33, Mohit Anchlia wrote:
>>
>> On Wed, Mar 31, 2010 at 2:27 PM, Rainer Jung<ra...@kippdata.de>
>> wrote:
>>>
>>> Which version?
>>>
>>> If 1.2.28 or newer, look for error_escalation_time in
>>
>> Actually I am on 1.2.27 so can't use error escalation time. Is there
>> any other way I can do it? I am seeing real odd behaviour with mod_jk.
>
> No, there was a change in 1.2.27:
>
> LB: Do not put loadbalancer node in error state if there is opened channel.
> This fixes the bug when new connection fails due to busyness, causing opened
> connections fail stickyness. This brings back per-node busy counter and
> private state array for each request. We can mark the state as error for
> failover to work while still operating and reporting node as OK if there are
> opened working connections.
Thanks! this is what I am not understanding that when box is down
there are no open connections to that box, because box is down. So why
will that worker not go in ERR state. And err 111 and 115 clearly
indicate that.
Other question is, as soon as box comes backup it goes in ERR state as
long as httpd2 is down.
So it seems odd that in first case where it really should put worker
in ERR state, it doesn't do that.
>
> That change motivated the addition of error_escalation_time in order to be
> able to stick with the previous behaviour. You will have to update to 1.2.28
> or beyond.
>
> Regards,
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk behaviour during failure
Posted by Rainer Jung <ra...@kippdata.de>.
On 31.03.2010 23:33, Mohit Anchlia wrote:
> On Wed, Mar 31, 2010 at 2:27 PM, Rainer Jung<ra...@kippdata.de> wrote:
>> Which version?
>>
>> If 1.2.28 or newer, look for error_escalation_time in
>
> Actually I am on 1.2.27 so can't use error escalation time. Is there
> any other way I can do it? I am seeing real odd behaviour with mod_jk.
No, there was a change in 1.2.27:
LB: Do not put loadbalancer node in error state if there is opened
channel. This fixes the bug when new connection fails due to busyness,
causing opened connections fail stickyness. This brings back per-node
busy counter and private state array for each request. We can mark the
state as error for failover to work while still operating and reporting
node as OK if there are opened working connections.
That change motivated the addition of error_escalation_time in order to
be able to stick with the previous behaviour. You will have to update to
1.2.28 or beyond.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk behaviour during failure
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mohit,
On 4/1/2010 5:04 PM, Mohit Anchlia wrote:
> On Thu, Apr 1, 2010 at 11:43 AM, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>> The default is printed in the documentation:
>>
>> http://tomcat.apache.org/connectors-doc/reference/workers.html
>
> Sorry but I don't see the option listed for default behaviour when
> recovery_option is not specified.
>
> I do know that I set to 7 so that I get the benefit of bit 1, 2 and 4.
The default is 0: no bits set. That would imply that you get the
benefits of none of the options.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAku2DFwACgkQ9CaO5/Lv0PCklgCaA+b/ywkvxdxyHrNHw/j6/Dh/
fYAAoLcGiNTU3Jk8wIv378ngronAGwuZ
=Rdn0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk behaviour during failure
Posted by Mohit Anchlia <mo...@gmail.com>.
On Thu, Apr 1, 2010 at 11:43 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mohit,
>
> On 4/1/2010 11:35 AM, Mohit Anchlia wrote:
>> I tested that leaving server down and in 15mt test the worker never
>> went to ERR state while the node was down.
>>
>> Could someone please advise?
>
> You'll have to wait for MLaden or Rainer to comment.
Could Rainer or MLaden advise?
>
>> I have couple more questions:
>>
>> - What's the default behaviour of recovery_option when not specified?
>> Currently it's specified as 7 but if I don't specify in conf then what
>> will happen?
>
> The default is printed in the documentation:
>
> http://tomcat.apache.org/connectors-doc/reference/workers.html
>
Sorry but I don't see the option listed for default behaviour when
recovery_option is not specified.
I do know that I set to 7 so that I get the benefit of bit 1, 2 and 4.
>> - What's the advantage of setting connection_min_size to 0?
>
> If you mean connection_pool_minsize, then I don't know why you'd bother
> doing this. Has someone suggested that connection_pool_minsize=0 is
> somehow advantageous?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAku06WQACgkQ9CaO5/Lv0PCUbACgp2pIaIFK2H5nkAFfK8dJCRCD
> ApkAmgJ2P8TTLDWBar46eRA5s8YXQSGy
> =mC6n
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk behaviour during failure
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mohit,
On 4/1/2010 11:35 AM, Mohit Anchlia wrote:
> I tested that leaving server down and in 15mt test the worker never
> went to ERR state while the node was down.
>
> Could someone please advise?
You'll have to wait for MLaden or Rainer to comment.
> I have couple more questions:
>
> - What's the default behaviour of recovery_option when not specified?
> Currently it's specified as 7 but if I don't specify in conf then what
> will happen?
The default is printed in the documentation:
http://tomcat.apache.org/connectors-doc/reference/workers.html
> - What's the advantage of setting connection_min_size to 0?
If you mean connection_pool_minsize, then I don't know why you'd bother
doing this. Has someone suggested that connection_pool_minsize=0 is
somehow advantageous?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAku06WQACgkQ9CaO5/Lv0PCUbACgp2pIaIFK2H5nkAFfK8dJCRCD
ApkAmgJ2P8TTLDWBar46eRA5s8YXQSGy
=mC6n
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk behaviour during failure
Posted by Mohit Anchlia <mo...@gmail.com>.
On Wed, Mar 31, 2010 at 3:35 PM, Mohit Anchlia <mo...@gmail.com> wrote:
> On Wed, Mar 31, 2010 at 3:29 PM, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Mohit,
>>
>> On 3/31/2010 5:33 PM, Mohit Anchlia wrote:
>>> On Wed, Mar 31, 2010 at 2:27 PM, Rainer Jung <ra...@kippdata.de> wrote:
>>>> Which version?
>>>>
>>>> If 1.2.28 or newer, look for error_escalation_time in
>>>
>>> Actually I am on 1.2.27 so can't use error escalation time. Is there
>>> any other way I can do it? I am seeing real odd behaviour with mod_jk.
>>> It does change to ERR but only when box is pingable. Can't seem to
>>> find any other way of configuring it such that the failed worker is
>>> considered as global error.
>>
>> What happens if the backend server never comes back up? Try bringing it
>> down and waiting. How long does it take for mod_jk to put that worker
>> into ERR state? Or, are you actually required to bring-up the backend
>> server in order to achieve the ERR state?
>
> I tested that leaving server down and in 15mt test the worker never
> went to ERR state while the node was down.
Could someone please advise?
I have couple more questions:
- What's the default behaviour of recovery_option when not specified?
Currently it's specified as 7 but if I don't specify in conf then what
will happen?
- What's the advantage of setting connection_min_size to 0?
>
>>
>> - -chris
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAkuzzNEACgkQ9CaO5/Lv0PBOEgCgw6/ENt2t36dnG+9nRwNA7tCj
>> H1QAoMOOt0MDkjPSZr0gjQEZ/TRpQos/
>> =+qy3
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk behaviour during failure
Posted by Mohit Anchlia <mo...@gmail.com>.
On Wed, Mar 31, 2010 at 3:29 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mohit,
>
> On 3/31/2010 5:33 PM, Mohit Anchlia wrote:
>> On Wed, Mar 31, 2010 at 2:27 PM, Rainer Jung <ra...@kippdata.de> wrote:
>>> Which version?
>>>
>>> If 1.2.28 or newer, look for error_escalation_time in
>>
>> Actually I am on 1.2.27 so can't use error escalation time. Is there
>> any other way I can do it? I am seeing real odd behaviour with mod_jk.
>> It does change to ERR but only when box is pingable. Can't seem to
>> find any other way of configuring it such that the failed worker is
>> considered as global error.
>
> What happens if the backend server never comes back up? Try bringing it
> down and waiting. How long does it take for mod_jk to put that worker
> into ERR state? Or, are you actually required to bring-up the backend
> server in order to achieve the ERR state?
I tested that leaving server down and in 15mt test the worker never
went to ERR state while the node was down.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuzzNEACgkQ9CaO5/Lv0PBOEgCgw6/ENt2t36dnG+9nRwNA7tCj
> H1QAoMOOt0MDkjPSZr0gjQEZ/TRpQos/
> =+qy3
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk behaviour during failure
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mohit,
On 3/31/2010 5:33 PM, Mohit Anchlia wrote:
> On Wed, Mar 31, 2010 at 2:27 PM, Rainer Jung <ra...@kippdata.de> wrote:
>> Which version?
>>
>> If 1.2.28 or newer, look for error_escalation_time in
>
> Actually I am on 1.2.27 so can't use error escalation time. Is there
> any other way I can do it? I am seeing real odd behaviour with mod_jk.
> It does change to ERR but only when box is pingable. Can't seem to
> find any other way of configuring it such that the failed worker is
> considered as global error.
What happens if the backend server never comes back up? Try bringing it
down and waiting. How long does it take for mod_jk to put that worker
into ERR state? Or, are you actually required to bring-up the backend
server in order to achieve the ERR state?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuzzNEACgkQ9CaO5/Lv0PBOEgCgw6/ENt2t36dnG+9nRwNA7tCj
H1QAoMOOt0MDkjPSZr0gjQEZ/TRpQos/
=+qy3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk behaviour during failure
Posted by Mohit Anchlia <mo...@gmail.com>.
On Wed, Mar 31, 2010 at 2:27 PM, Rainer Jung <ra...@kippdata.de> wrote:
> Which version?
>
> If 1.2.28 or newer, look for error_escalation_time in
Actually I am on 1.2.27 so can't use error escalation time. Is there
any other way I can do it? I am seeing real odd behaviour with mod_jk.
It does change to ERR but only when box is pingable. Can't seem to
find any other way of configuring it such that the failed worker is
considered as global error.
>
> http://tomcat.apache.org/connectors-doc/reference/workers.html
>
> Read the description and try setting it to "0".
>
> Regards,
>
> Rainer
>
> On 31.03.2010 23:09, Mohit Anchlia wrote:
>>
>> I am seeing weird behaviour here.
>>
>> What I am seeing is that when server is not pingable (when I reboot
>> or shutdown) anymore mod_jk keeps logging errors 111 (connection
>> refused) and errors 115 continuously and during this timeperiod if I
>> look at "JkStatus" the State of the corresponding worker is still "OK"
>> (which is incorrect in this case since server is not pingable). During
>> this time period response times are still around 2-4 secs as compared
>> to 300 ms. When everything is good our requests take 300 ms.
>>
>> Now once the server comes up (pingable) the state of the worker is
>> "ERR" and at this point everything returns back to normal. So it looks
>> like until server is pingable mod_jk doesn't put that worker in "ERR"
>> state. So my question is what can I do in worker.properties such that
>> worker goes in ERR state automatically when server or the machine
>> completely goes down? It's kind of odd that mod_jk doesn't put the
>> worker in ERR state when the box that worker is tied to is not
>> pingable?
>>
>> ---
>>
>> worker.tc.type=lb
>> worker.tc.balance_workers=host1,host2,host3,host4,host5,host6
>> worker.tc.sticky_session=true
>>
>> worker.host1.type=ajp13
>> worker.host1.port=8009
>> worker.host1.host=host
>> worker.host1.socket_keepalive=true
>> worker.host1.prepost_timeout=5000
>> worker.host1.connect_timeout=5000
>> worker.host1.retries=1
>> worker.host1.socket_connect_timeout=1000
>> worker.host1.connection_pool_minsize=0
>> worker.host1.connection_pool_timeout=20
>> worker.host1.recovery_options=7
>> worker.host1.ping_mode=A
>> worker.host1.ping_timeout=5000
>>
>> ...
>>
>> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [info]
>> ajp_connect_to_endpoint::jk_ajp_common.c (922): Failed opening socket
>> to (10.10.81.153:8009) (errno=115)
>> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [error]
>> ajp_send_request::jk_ajp_common.c (1467): (host5) connecting to
>> backend failed. Tomcat is probably not started or is listening on the
>> wrong port (errno=115)
>> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [info]
>> ajp_service::jk_ajp_common.c (2407): (host5) sending request to tomcat
>> failed (recoverable), because of error during request sending
>> (attempt=1)
>> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [error]
>> ajp_service::jk_ajp_common.c (2426): (host5) connecting to tomcat
>> failed.
>> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [debug]
>> ajp_reset_endpoint::jk_ajp_common.c (743): (host5) resetting endpoint
>> with sd = 4294967295 (socket shutdown)
>> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [debug]
>> ajp_done::jk_ajp_common.c (2850): recycling connection pool slot=0 for
>> worker host5
>> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [info]
>> service::jk_lb_worker.c (1347): service failed, worker host5 is in
>> local error state
>> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [debug]
>> service::jk_lb_worker.c (1358): recoverable error... will try to
>> recover on other worker
>> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [debug]
>> get_most_suitable_worker::jk_lb_worker.c (969): found best worker
>> host6 (host6) using method 'Request'
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk behaviour during failure
Posted by Rainer Jung <ra...@kippdata.de>.
Which version?
If 1.2.28 or newer, look for error_escalation_time in
http://tomcat.apache.org/connectors-doc/reference/workers.html
Read the description and try setting it to "0".
Regards,
Rainer
On 31.03.2010 23:09, Mohit Anchlia wrote:
> I am seeing weird behaviour here.
>
> What I am seeing is that when server is not pingable (when I reboot
> or shutdown) anymore mod_jk keeps logging errors 111 (connection
> refused) and errors 115 continuously and during this timeperiod if I
> look at "JkStatus" the State of the corresponding worker is still "OK"
> (which is incorrect in this case since server is not pingable). During
> this time period response times are still around 2-4 secs as compared
> to 300 ms. When everything is good our requests take 300 ms.
>
> Now once the server comes up (pingable) the state of the worker is
> "ERR" and at this point everything returns back to normal. So it looks
> like until server is pingable mod_jk doesn't put that worker in "ERR"
> state. So my question is what can I do in worker.properties such that
> worker goes in ERR state automatically when server or the machine
> completely goes down? It's kind of odd that mod_jk doesn't put the
> worker in ERR state when the box that worker is tied to is not
> pingable?
>
> ---
>
> worker.tc.type=lb
> worker.tc.balance_workers=host1,host2,host3,host4,host5,host6
> worker.tc.sticky_session=true
>
> worker.host1.type=ajp13
> worker.host1.port=8009
> worker.host1.host=host
> worker.host1.socket_keepalive=true
> worker.host1.prepost_timeout=5000
> worker.host1.connect_timeout=5000
> worker.host1.retries=1
> worker.host1.socket_connect_timeout=1000
> worker.host1.connection_pool_minsize=0
> worker.host1.connection_pool_timeout=20
> worker.host1.recovery_options=7
> worker.host1.ping_mode=A
> worker.host1.ping_timeout=5000
>
> ...
>
> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [info]
> ajp_connect_to_endpoint::jk_ajp_common.c (922): Failed opening socket
> to (10.10.81.153:8009) (errno=115)
> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [error]
> ajp_send_request::jk_ajp_common.c (1467): (host5) connecting to
> backend failed. Tomcat is probably not started or is listening on the
> wrong port (errno=115)
> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [info]
> ajp_service::jk_ajp_common.c (2407): (host5) sending request to tomcat
> failed (recoverable), because of error during request sending
> (attempt=1)
> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [error]
> ajp_service::jk_ajp_common.c (2426): (host5) connecting to tomcat
> failed.
> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [debug]
> ajp_reset_endpoint::jk_ajp_common.c (743): (host5) resetting endpoint
> with sd = 4294967295 (socket shutdown)
> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [debug]
> ajp_done::jk_ajp_common.c (2850): recycling connection pool slot=0 for
> worker host5
> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [info]
> service::jk_lb_worker.c (1347): service failed, worker host5 is in
> local error state
> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [debug]
> service::jk_lb_worker.c (1358): recoverable error... will try to
> recover on other worker
> [Wed Mar 31 13:39:15.517 2010] [19700:4143184544] [debug]
> get_most_suitable_worker::jk_lb_worker.c (969): found best worker
> host6 (host6) using method 'Request'
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org