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 2009/02/25 00:00:59 UTC
mod_jk not working as expected - is there a bug??
Reposting:
Apache Server - 2.2
Tomcat server 6
Jboss - 4.2
We have Web Servers talking to Jboss App Servers over mod_jk. When we
do our patch or upgrade of software we do it in rolling fashion so
that there is "0" customer impact. But it looks like mod_jk load
balancer on Web server doesn't detect it as soon as Jboss App Server
goes down. Our goal is to have 0 customer impact. So my question is
what can we do to overcome this problem. Web Server sees Http Error
Code 503.
Information from log file:
[Mon Feb 23 13:39:42.146 2009] [31682:4143745888] [error]
ajp_connection_tcp_get_message::jk_ajp_common.c (966): (appfe4) can't
receive the response message from tomcat, network problems or tomcat
(10.10.81.89:8009) is down (errno=104)
[Mon Feb 23 13:39:42.147 2009] [31682:4143745888] [error]
ajp_service::jk_ajp_common.c (2097): (appfe4) Connecting to tomcat
failed. Tomcat is probably not started or is listening on the wrong
port
On Tue, Feb 24, 2009 at 1:41 PM, Rainer Jung <ra...@kippdata.de> wrote:
> On 24.02.2009 19:18, Mohit Anchlia wrote:
>>
>> We have Web Servers talking to Jboss App Servers over mod_jk. When we
>> do our patch or upgrade of software we do it in rolling fashion so
>> that there is "0" customer impact. But it looks like mod_jk load
>> balancer on Web server doesn't detect it as soon as Jboss App Server
>> goes down. Our goal is to have 0 customer impact. So my question is
>> what can we do to overcome this problem. Web Server sees Http Error
>> Code 503.
>
> No configuration, no version information, no log files: not much we can help
> with.
>
> Also: your message subject is not likely to attract helping people.
>
> Sorry,
>
> 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 not working as expected - is there a bug??
Posted by Rainer Jung <ra...@kippdata.de>.
On 25.02.2009 16:50, János Löbb wrote:
> I am not sure the stickiness should be attached to the tc worker. I
> would rather do it for the the real workers level, that is at appfe[1234].
>
> Consider also
>
> worker.appfe[1234].sticky_session_force = False
>
> for each appfe[1234] worker.
The page
http://tomcat.apache.org/connectors-doc/reference/workers.html
specifies the properties. Both sticky_session and sticky_session_force
are for lb workers. Setting sticky_session_force to false is the default
(as is setting sticky_session to true).
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
Posted by János Löbb <ja...@yale.edu>.
I am not sure the stickiness should be attached to the tc worker. I
would rather do it for the the real workers level, that is at
appfe[1234].
Consider also
worker.appfe[1234].sticky_session_force = False
for each appfe[1234] worker.
János
On Feb 24, 2009, at 8:47 PM, Mohit Anchlia wrote:
> In httpd conf I just see JkMount and no other directive. I searched
> for Jk.
>
> Here is workers.properties file:
> ##
> worker.list=status,tc
>
> ## Worker Configuration##
>
> # All entries in this section take the form:
> # worker.<workername>.<directive>=<value>
> # Worker names are defined in the worker.list directive above.
>
>
> # Configuration specifying the worker named "status" as a status
> worker.
> # This worker can be used to administer the other configured workers.
> worker.status.type=status
>
>
> # Configuration for the default load balancer worker.
> # Uncomment the configuration for the "tc"
> # worker, and the two "node" workers below to enable.
> # Also add "lb" to the workers.list directive
> # above. The default for the load balancer worker is
> # round-robin distribution of requests over
> # all active nodes. There are currently two nodes set
> # up for the load balanced worker, add more
> # to this list if required. Sticky sessions is defaulted to true.
> worker.tc.type=lb
> worker.tc.balance_workers=appfe1,appfe2,appfe3,appfe4
> worker.tc.sticky_session=true
>
>
> # Two load balanced workers, called node1 and node2.
> # Copy the configurations and add to the
> # worker.tc.balanced_workers
> # list above to add more nodes to the Tomcat cluster.
>
>
> # appfe1
> worker.appfe1.type=ajp13
> worker.appfe1.port=8009
> worker.appfe1.host=appfe1
> worker.appfe1.socket_timeout=5
> worker.appfe1.socket_keepalive=true
> worker.appfe1.prepost_timeout=5
> worker.appfe1.connect_timeout=5000
> worker.appfe1.retries=3
> worker.appfe1.recycle_timeout=900
>
> # Refererence BHP Apache tuning guide before uncomment the following
> line. The unit of reply_timeout is millisecond.
> #worker.appfe1.reply_timeout=0
>
> # appfe2
> worker.appfe2.type=ajp13
> worker.appfe2.port=8009
> worker.appfe2.host=appfe2
> worker.appfe2.socket_timeout=5
> worker.appfe2.socket_keepalive=true
> worker.appfe2.prepost_timeout=5
> worker.appfe2.connect_timeout=5000
> worker.appfe2.retries=3
> worker.appfe2.recycle_timeout=900
>
> # Refererence BHP Apache tuning guide before uncomment the following
> line. The unit of reply_timeout is millisecond.
> #worker.appfe2.reply_timeout=0
>
> # appfe3
> worker.appfe3.type=ajp13
> worker.appfe3.port=8009
> worker.appfe3.host=appfe3
> worker.appfe3.socket_timeout=5
> worker.appfe3.socket_keepalive=true
> worker.appfe3.prepost_timeout=5
> worker.appfe3.connect_timeout=5000
> worker.appfe3.retries=3
> worker.appfe3.recycle_timeout=900
>
> # Refererence BHP Apache tuning guide before uncomment the following
> line. The unit of reply_timeout is millisecond.
> #worker.appfe3.reply_timeout=0
>
> # appfe4
> worker.appfe4.type=ajp13
> worker.appfe4.port=8009
> worker.appfe4.host=appfe4
> worker.appfe4.socket_timeout=5
> worker.appfe4.socket_keepalive=true
> worker.appfe4.prepost_timeout=5
> worker.appfe4.connect_timeout=5000
> worker.appfe4.retries=3
> worker.appfe4.recycle_timeout=900
>
> # Refererence BHP Apache tuning guide before uncomment the following
> line. The unit of reply_timeout is millisecond.
> #worker.appfe4.reply_timeout=0
>
> On Tue, Feb 24, 2009 at 4:50 PM, Rainer Jung
> <ra...@kippdata.de> wrote:
>> On 25.02.2009 00:00, Mohit Anchlia wrote:
>>>
>>> Reposting:
>>>
>>> Apache Server - 2.2
>>> Tomcat server 6
>>> Jboss - 4.2
>>>
>>> We have Web Servers talking to Jboss App Servers over mod_jk. When
>>> we
>>> do our patch or upgrade of software we do it in rolling fashion so
>>> that there is "0" customer impact. But it looks like mod_jk load
>>> balancer on Web server doesn't detect it as soon as Jboss App Server
>>> goes down. Our goal is to have 0 customer impact. So my question is
>>> what can we do to overcome this problem. Web Server sees Http Error
>>> Code 503.
>>>
>>> Information from log file:
>>>
>>> [Mon Feb 23 13:39:42.146 2009] [31682:4143745888] [error]
>>> ajp_connection_tcp_get_message::jk_ajp_common.c (966): (appfe4)
>>> can't
>>> receive the response message from tomcat, network problems or tomcat
>>> (10.10.81.89:8009) is down (errno=104)
>>> [Mon Feb 23 13:39:42.147 2009] [31682:4143745888] [error]
>>> ajp_service::jk_ajp_common.c (2097): (appfe4) Connecting to tomcat
>>> failed. Tomcat is probably not started or is listening on the wrong
>>> port
>>
>> This means that mod_jk detected that your backend is down and thus
>> puts it
>> into an error state. All following requests will no longer be sent
>> to this
>> backend. Once a minute it will send a request there and try, but as
>> long as
>> it is down this test will not succeed and thus all requests will be
>> sent to
>> other nodes.
>>
>> The first request that gets sent to the backend you stopped might
>> get an
>> error back. If you want to prevent that from happening, use Cping/
>> Cpong:
>>
>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>>
>> so we will detect the broken node before actually sending a request
>> there.
>> More details are not possible to give without your JK configuration
>> (Jk
>> directive sin httpd configuration files, workers.properties and if
>> used
>> uriworkermap.properties).
>>
>> The line number of the above message tells me you are using mod_jk
>> 1.2.25.
>> Although there's nothing wrong in principal with 1.2.25, we always
>> try to
>> improve and you might consider switching to 1.2.27.
>>
>> You should also increase your JkLogLevel to info. As long as only
>> occasional
>> info messages are in your log file everything is fine, but once error
>> messages show up, the additional info messages contain useful
>> formation.
>>
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
I was looking at the manual and didn't see a way to automatically set
the worker to stop. I'll test it today with the way you suggested and
post more questions ..
On Fri, Mar 6, 2009 at 12:35 AM, Rainer Jung <ra...@kippdata.de> wrote:
> On 06.03.2009 09:27, Mohit Anchlia wrote:
>>
>> Is there a way to dynamically move workers in and out of service using
>> status worker.
>
> Please first have a look at the status worker and get some experience with
> it before posting more basic questions.
>
> 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 not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
Resending with more information and attachment:
Apache 2.11, mod_jk/1.2.28:
There seems to be a problem with activation of status worker JkStatus.
Even after explicitly saying "stopped" for one of the workers the
"Act" keeps going back and forth. When I refresh that page it keeps
switching between "OK" and "STP". I even tried using wget but that
doesn't work either. And I still see traffic being sent
to that worker.
wget:
http://host2535.pharos.in.com/JkStatus?cmd=update&from=list&w=tc&sw=host2532&vwa=2&wf=1&wn=host2532&wr=&wc=&wd=0&mime=txt"
I have even tried vwa=s. I also tried opening one browser session
stopping the worker (jkStatus) and then opening a new session to check
the status. The status still keeps going back and forth. It shows
"ACT" and then you refresh it shows "STP" and then you refresh again
it shows "ACT". Nothing seems to be working.
Is this a known bug?
Earlier when we were on previous version of mod_jk this used to work
fine. Attached is the screen shot
On Sat, Oct 24, 2009 at 7:51 AM, Mohit Anchlia <mo...@gmail.com> wrote:
> Apache 2.11, mod_jk/1.2.28:
>
> There seems to be a problem with activation of status worker JkStatus.
> Even after explicitly saying "stopped" for one of the workers the
> "Act" keeps going back and forth. When I refresh that page it keeps
> switching between "OK" and "STP". And I still see traffic being sent
> to that worker. Is this a known bug?
>
> Earlier when we were on previous version of mod_jk this
>
> On Fri, Mar 6, 2009 at 2:02 PM, Rainer Jung <ra...@kippdata.de> wrote:
>> On 06.03.2009 21:42, Mohit Anchlia wrote:
>>>
>>> In addition to questions that I have in below email, I have couple of
>>> question.
>>>
>>> 1. activation property disable - Does it first turn off new requests
>>> to that worker and then disable the worker after finishing old
>>> requests. So is this the best way to see 0 customer impact?
>>> 2. activation propery stopped - Does it throw away existing sessions
>>> and also stop taking new requests.
>>
>> Please read about activation on
>>
>> http://tomcat.apache.org/connectors-doc/reference/workers.html
>>
>> Stopped: do not allow any requests being send to the worker.
>>
>> Disabled: Only requests which carry a session, that is sticky on the worker
>> will go the the worker. No other requests will be send there.
>>
>> Use "disable" to dry out a worker, use "stoppped" directly before you
>> actually want to take it out of production.
>>
>>> Also I couldn't find way to see how mod_jk is behaving in the log
>>> file. I turned tracing on for JkLogLevel.
>>
>> I don't know what you mean by "behaving".
>>
>> Regards,
>>
>> Rainer
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
Re: mod_jk not working as expected - is there a bug??
Posted by Rainer Jung <ra...@kippdata.de>.
Hi,
On 10.03.2009 19:47, Mohit Anchlia wrote:
> I am currently testing this. Hoping this will help us achieve 0
> customer impact when we upgrade our system.
>
> Is it possible for mod_jk to check 2 ports to determine if that worker
> should be out of service? For eg: if 8010 is down but 8009 port is up
> then bring that worker out of service? But the data port will continue
> to be 8009. Here is the problem, to successfully receive the traffic
> we have 2 dependencies 1. App server (port 8009) and 2. Queue server
> (port 8010). If anyone of those servers are down then we can't receive
> the traffic. But mod_jk only knows about 8009.
No, mod_jk only knows about Tomcat AJP connectors. If you wat to
coordinate a bigger more complex system, you need to do this externally.
mod_jk only provides you with information about the state of the part of
the system it knows (the configured Tomcat AJP connectors, e.g. workers)
and it provides entry points to change the configuration state, e.g.
switching activation via status worker.
The rest is up to you :)
Regards,
Rainer
> On Fri, Mar 6, 2009 at 2:02 PM, Rainer Jung<ra...@kippdata.de> wrote:
>> On 06.03.2009 21:42, Mohit Anchlia wrote:
>>> In addition to questions that I have in below email, I have couple of
>>> question.
>>>
>>> 1. activation property disable - Does it first turn off new requests
>>> to that worker and then disable the worker after finishing old
>>> requests. So is this the best way to see 0 customer impact?
>>> 2. activation propery stopped - Does it throw away existing sessions
>>> and also stop taking new requests.
>> Please read about activation on
>>
>> http://tomcat.apache.org/connectors-doc/reference/workers.html
>>
>> Stopped: do not allow any requests being send to the worker.
>>
>> Disabled: Only requests which carry a session, that is sticky on the worker
>> will go the the worker. No other requests will be send there.
>>
>> Use "disable" to dry out a worker, use "stoppped" directly before you
>> actually want to take it out of production.
>>
>>> Also I couldn't find way to see how mod_jk is behaving in the log
>>> file. I turned tracing on for JkLogLevel.
>> I don't know what you mean by "behaving".
>>
>> Regards,
>>
>> Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
I am currently testing this. Hoping this will help us achieve 0
customer impact when we upgrade our system.
Is it possible for mod_jk to check 2 ports to determine if that worker
should be out of service? For eg: if 8010 is down but 8009 port is up
then bring that worker out of service? But the data port will continue
to be 8009. Here is the problem, to successfully receive the traffic
we have 2 dependencies 1. App server (port 8009) and 2. Queue server
(port 8010). If anyone of those servers are down then we can't receive
the traffic. But mod_jk only knows about 8009.
On Fri, Mar 6, 2009 at 2:02 PM, Rainer Jung <ra...@kippdata.de> wrote:
> On 06.03.2009 21:42, Mohit Anchlia wrote:
>>
>> In addition to questions that I have in below email, I have couple of
>> question.
>>
>> 1. activation property disable - Does it first turn off new requests
>> to that worker and then disable the worker after finishing old
>> requests. So is this the best way to see 0 customer impact?
>> 2. activation propery stopped - Does it throw away existing sessions
>> and also stop taking new requests.
>
> Please read about activation on
>
> http://tomcat.apache.org/connectors-doc/reference/workers.html
>
> Stopped: do not allow any requests being send to the worker.
>
> Disabled: Only requests which carry a session, that is sticky on the worker
> will go the the worker. No other requests will be send there.
>
> Use "disable" to dry out a worker, use "stoppped" directly before you
> actually want to take it out of production.
>
>> Also I couldn't find way to see how mod_jk is behaving in the log
>> file. I turned tracing on for JkLogLevel.
>
> I don't know what you mean by "behaving".
>
> 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 not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
Apache 2.11, mod_jk/1.2.28:
There seems to be a problem with activation of status worker JkStatus.
Even after explicitly saying "stopped" for one of the workers the
"Act" keeps going back and forth. When I refresh that page it keeps
switching between "OK" and "STP". And I still see traffic being sent
to that worker. Is this a known bug?
Earlier when we were on previous version of mod_jk this
On Fri, Mar 6, 2009 at 2:02 PM, Rainer Jung <ra...@kippdata.de> wrote:
> On 06.03.2009 21:42, Mohit Anchlia wrote:
>>
>> In addition to questions that I have in below email, I have couple of
>> question.
>>
>> 1. activation property disable - Does it first turn off new requests
>> to that worker and then disable the worker after finishing old
>> requests. So is this the best way to see 0 customer impact?
>> 2. activation propery stopped - Does it throw away existing sessions
>> and also stop taking new requests.
>
> Please read about activation on
>
> http://tomcat.apache.org/connectors-doc/reference/workers.html
>
> Stopped: do not allow any requests being send to the worker.
>
> Disabled: Only requests which carry a session, that is sticky on the worker
> will go the the worker. No other requests will be send there.
>
> Use "disable" to dry out a worker, use "stoppped" directly before you
> actually want to take it out of production.
>
>> Also I couldn't find way to see how mod_jk is behaving in the log
>> file. I turned tracing on for JkLogLevel.
>
> I don't know what you mean by "behaving".
>
> 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 not working as expected - is there a bug??
Posted by Rainer Jung <ra...@kippdata.de>.
On 06.03.2009 21:42, Mohit Anchlia wrote:
> In addition to questions that I have in below email, I have couple of question.
>
> 1. activation property disable - Does it first turn off new requests
> to that worker and then disable the worker after finishing old
> requests. So is this the best way to see 0 customer impact?
> 2. activation propery stopped - Does it throw away existing sessions
> and also stop taking new requests.
Please read about activation on
http://tomcat.apache.org/connectors-doc/reference/workers.html
Stopped: do not allow any requests being send to the worker.
Disabled: Only requests which carry a session, that is sticky on the
worker will go the the worker. No other requests will be send there.
Use "disable" to dry out a worker, use "stoppped" directly before you
actually want to take it out of production.
> Also I couldn't find way to see how mod_jk is behaving in the log
> file. I turned tracing on for JkLogLevel.
I don't know what you mean by "behaving".
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
In addition to questions that I have in below email, I have couple of question.
1. activation property disable - Does it first turn off new requests
to that worker and then disable the worker after finishing old
requests. So is this the best way to see 0 customer impact?
2. activation propery stopped - Does it throw away existing sessions
and also stop taking new requests.
Also I couldn't find way to see how mod_jk is behaving in the log
file. I turned tracing on for JkLogLevel.
On Fri, Mar 6, 2009 at 10:41 AM, Mohit Anchlia <mo...@gmail.com> wrote:
> Thanks ..I got following URL from the browser, which is different then
> what you suggested. Does this look ok?
>
> http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=0&wf=1&wn=appfe1&wr=&wc=&wd=0
>
> so it look like when I want one node out of service I do the following:
>
> Execute GET http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=2&wf=1&wn=appfe1&wr=&wc=&wd=0
>
> and when I want that node in service I do:
>
> http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=0&wf=1&wn=appfe1&wr=&wc=&wd=0
>
> I tried enabling JkLog to trace but couldn't see where the requests
> are being forwarded too? I see something like :
>
> [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug]
> ajp_connection_tcp_send_message::jk_ajp_common.c (911): 0180 48 50
> 01 02 85 15 30 24 D1 3E 54 09 54 4C C1 A1 - HP....0$.>T.TL..
> [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [debug]
> status_get_string::jk_status.c (702): retrieved string arg 'wd' as '0'
> [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug]
> ajp_connection_tcp_send_message::jk_ajp_common.c (911): 0190 7A 09
> 40 B8 B0 82 EA 4A 9F 00 46 2A E5 28 B5 02 - z.@....J..F*.(..
> [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [trace]
> reset_lb_values::jk_lb_worker.c (257): enter
> [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug]
> ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01a0 15 08
> 40 09 2A A8 18 E2 09 47 28 01 62 C6 14 8A - ..@.*....G(.b...
> [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [trace]
> reset_lb_values::jk_lb_worker.c (263): exit
> [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug]
> ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01b0 22 49
> 01 CE CF 52 91 12 E4 48 49 A4 2A E0 82 00 - "I...R...HI.*...
>
>
> But I can't tell if the requests to appfe1 are no longer being
> directed to appfe1 node.
>
> On Fri, Mar 6, 2009 at 10:14 AM, Rainer Jung <ra...@kippdata.de> wrote:
>> On 06.03.2009 18:57, Mohit Anchlia wrote:
>>>
>>> So I created new JkMount /JkStatus status under VirtualHost. Went to
>>> the page and saw different properties, it looks like I need to change
>>> the Activation on individual worker. When I click "E" in front of that
>>> worker it takes me to the page where I can edit the activation
>>> property. I think if I set it to "stopped" balancer will take it out
>>> of service. Only question I have is how can I automatically do that.
>>
>>> Can I do something like:
>>
>>>
>>> http://10.10.80.55/JkStatus?cmd=edit&from=list&w=tc&sw=appfe1&activation=stopped
>>
>> Yes you can. All requests to the status worker are GET requests, so
>> everything you can do in the GUI you can also put into a script. Simply copy
>> the URLs form your browser.
>>
>> The documentation page also lists all request attributes with their meaning.
>>
>> According to this page you need to use "vwa=s" instead of
>> "activation=stopped" (at least for version 1.2.27; "s" instead of "stopped"
>> is not important, but "vwa" instead of "activation" is).
>>
>> You can also add mime=txt so that your script gets back an easier to
>> understand answer.
>>
>>> or something like that automatically will change the activiation as I
>>> move servers in and out of service?
>>
>> You can write a script for this, that uses the above URLs with a tool like
>> e.g. curl.
>>
>> Caution:
>>
>> 1) Secure the URL. Your web server has ways to do that, e.g. with a user and
>> password.
>>
>> 2) Activation changes via the status worker are not persistent. When your
>> web server is restarted, activation switches back to what is in your
>> workers.proprties. If you want to change activation in a persistant way, you
>> also have to change your workers.properties.
>>
>> 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 not working as expected - is there a bug??
Posted by Rainer Jung <ra...@kippdata.de>.
On 06.03.2009 19:41, Mohit Anchlia wrote:
> Thanks ..I got following URL from the browser, which is different then
> what you suggested. Does this look ok?
>
> http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=0&wf=1&wn=appfe1&wr=&wc=&wd=0
If it comes from the Browser, it is OK.
I guess you are using a version before 1.2.27. The arguments have
changed with 1.2.27, but will now be kept stable.
My cmd=edit was wrong, of course it is cmd=update.
"wa" is the previous way instead of "vwa", value "0" should mean active,
you need "2" or "s" for stopped (at least with 1.2.27, but simply check
it out, you can view the result again in the status worker display). You
don't need the from when used from a script, it is just for the GUI
redirect.
wf, wn, wr, wc and wd you don't need, if you only want to edit activation.
> so it look like when I want one node out of service I do the following:
>
> Execute GET http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=2&wf=1&wn=appfe1&wr=&wc=&wd=0
or shorter:
http://10.10.80.55/JkStatus?cmd=update&w=tc&sw=appfe1&wa=2
> and when I want that node in service I do:
>
> http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=0&wf=1&wn=appfe1&wr=&wc=&wd=0
or shorter
http://10.10.80.55/JkStatus?cmd=update&w=tc&sw=appfe1&wa=0
> I tried enabling JkLog to trace but couldn't see where the requests
> are being forwarded too? I see something like :
>
> [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug]
> ajp_connection_tcp_send_message::jk_ajp_common.c (911): 0180 48 50
> 01 02 85 15 30 24 D1 3E 54 09 54 4C C1 A1 - HP....0$.>T.TL..
> [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [debug]
> status_get_string::jk_status.c (702): retrieved string arg 'wd' as '0'
> [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug]
> ajp_connection_tcp_send_message::jk_ajp_common.c (911): 0190 7A 09
> 40 B8 B0 82 EA 4A 9F 00 46 2A E5 28 B5 02 - z.@....J..F*.(..
> [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [trace]
> reset_lb_values::jk_lb_worker.c (257): enter
> [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug]
> ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01a0 15 08
> 40 09 2A A8 18 E2 09 47 28 01 62 C6 14 8A - ..@.*....G(.b...
> [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [trace]
> reset_lb_values::jk_lb_worker.c (263): exit
> [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug]
> ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01b0 22 49
> 01 CE CF 52 91 12 E4 48 49 A4 2A E0 82 00 - "I...R...HI.*...
Any change done by the status worker gets logged immediately with info
log level.
> But I can't tell if the requests to appfe1 are no longer being
> directed to appfe1 node.
You can check that more easily by looking at the request counts in the
status worker display, whether they stil go up or are kept stable. The
display also shows you the actual activation status, which should change
from ACT to STP and back.
You can also log the lb member which was chosen for a request in the
Apache access log, by adding a log note to your LogFormat. Look for
mod_log_config on the page
http://tomcat.apache.org/connectors-doc/reference/apache.html
Finally you can also activate the access log of your backend to track,
whether they handle requests or not.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
Thanks ..I got following URL from the browser, which is different then
what you suggested. Does this look ok?
http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=0&wf=1&wn=appfe1&wr=&wc=&wd=0
so it look like when I want one node out of service I do the following:
Execute GET http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=2&wf=1&wn=appfe1&wr=&wc=&wd=0
and when I want that node in service I do:
http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=0&wf=1&wn=appfe1&wr=&wc=&wd=0
I tried enabling JkLog to trace but couldn't see where the requests
are being forwarded too? I see something like :
[Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (911): 0180 48 50
01 02 85 15 30 24 D1 3E 54 09 54 4C C1 A1 - HP....0$.>T.TL..
[Fri Mar 06 10:20:25.377 2009] [675:4143913824] [debug]
status_get_string::jk_status.c (702): retrieved string arg 'wd' as '0'
[Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (911): 0190 7A 09
40 B8 B0 82 EA 4A 9F 00 46 2A E5 28 B5 02 - z.@....J..F*.(..
[Fri Mar 06 10:20:25.377 2009] [675:4143913824] [trace]
reset_lb_values::jk_lb_worker.c (257): enter
[Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01a0 15 08
40 09 2A A8 18 E2 09 47 28 01 62 C6 14 8A - ..@.*....G(.b...
[Fri Mar 06 10:20:25.377 2009] [675:4143913824] [trace]
reset_lb_values::jk_lb_worker.c (263): exit
[Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01b0 22 49
01 CE CF 52 91 12 E4 48 49 A4 2A E0 82 00 - "I...R...HI.*...
But I can't tell if the requests to appfe1 are no longer being
directed to appfe1 node.
On Fri, Mar 6, 2009 at 10:14 AM, Rainer Jung <ra...@kippdata.de> wrote:
> On 06.03.2009 18:57, Mohit Anchlia wrote:
>>
>> So I created new JkMount /JkStatus status under VirtualHost. Went to
>> the page and saw different properties, it looks like I need to change
>> the Activation on individual worker. When I click "E" in front of that
>> worker it takes me to the page where I can edit the activation
>> property. I think if I set it to "stopped" balancer will take it out
>> of service. Only question I have is how can I automatically do that.
>
>> Can I do something like:
>
>>
>> http://10.10.80.55/JkStatus?cmd=edit&from=list&w=tc&sw=appfe1&activation=stopped
>
> Yes you can. All requests to the status worker are GET requests, so
> everything you can do in the GUI you can also put into a script. Simply copy
> the URLs form your browser.
>
> The documentation page also lists all request attributes with their meaning.
>
> According to this page you need to use "vwa=s" instead of
> "activation=stopped" (at least for version 1.2.27; "s" instead of "stopped"
> is not important, but "vwa" instead of "activation" is).
>
> You can also add mime=txt so that your script gets back an easier to
> understand answer.
>
>> or something like that automatically will change the activiation as I
>> move servers in and out of service?
>
> You can write a script for this, that uses the above URLs with a tool like
> e.g. curl.
>
> Caution:
>
> 1) Secure the URL. Your web server has ways to do that, e.g. with a user and
> password.
>
> 2) Activation changes via the status worker are not persistent. When your
> web server is restarted, activation switches back to what is in your
> workers.proprties. If you want to change activation in a persistant way, you
> also have to change your workers.properties.
>
> 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 not working as expected - is there a bug??
Posted by Rainer Jung <ra...@kippdata.de>.
On 06.03.2009 18:57, Mohit Anchlia wrote:
> So I created new JkMount /JkStatus status under VirtualHost. Went to
> the page and saw different properties, it looks like I need to change
> the Activation on individual worker. When I click "E" in front of that
> worker it takes me to the page where I can edit the activation
> property. I think if I set it to "stopped" balancer will take it out
> of service. Only question I have is how can I automatically do that.
> Can I do something like:
> http://10.10.80.55/JkStatus?cmd=edit&from=list&w=tc&sw=appfe1&activation=stopped
Yes you can. All requests to the status worker are GET requests, so
everything you can do in the GUI you can also put into a script. Simply
copy the URLs form your browser.
The documentation page also lists all request attributes with their meaning.
According to this page you need to use "vwa=s" instead of
"activation=stopped" (at least for version 1.2.27; "s" instead of
"stopped" is not important, but "vwa" instead of "activation" is).
You can also add mime=txt so that your script gets back an easier to
understand answer.
> or something like that automatically will change the activiation as I
> move servers in and out of service?
You can write a script for this, that uses the above URLs with a tool
like e.g. curl.
Caution:
1) Secure the URL. Your web server has ways to do that, e.g. with a user
and password.
2) Activation changes via the status worker are not persistent. When
your web server is restarted, activation switches back to what is in
your workers.proprties. If you want to change activation in a persistant
way, you also have to change your workers.properties.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
So I created new JkMount /JkStatus status under VirtualHost. Went to
the page and saw different properties, it looks like I need to change
the Activation on individual worker. When I click "E" in front of that
worker it takes me to the page where I can edit the activation
property. I think if I set it to "stopped" balancer will take it out
of service. Only question I have is how can I automatically do that.
Can I do something like:
http://10.10.80.55/JkStatus?cmd=edit&from=list&w=tc&sw=appfe1&activation=stopped
or something like that automatically will change the activiation as I
move servers in and out of service?
On Fri, Mar 6, 2009 at 12:35 AM, Rainer Jung <ra...@kippdata.de> wrote:
> On 06.03.2009 09:27, Mohit Anchlia wrote:
>>
>> Is there a way to dynamically move workers in and out of service using
>> status worker.
>
> Please first have a look at the status worker and get some experience with
> it before posting more basic questions.
>
> 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 not working as expected - is there a bug??
Posted by Rainer Jung <ra...@kippdata.de>.
On 06.03.2009 09:27, Mohit Anchlia wrote:
> Is there a way to dynamically move workers in and out of service using
> status worker.
Please first have a look at the status worker and get some experience
with it before posting more basic questions.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
Is there a way to dynamically move workers in and out of service using
status worker.
On Thu, Mar 5, 2009 at 10:34 PM, Rainer Jung <ra...@kippdata.de> wrote:
> On 06.03.2009 01:44, Mohit Anchlia wrote:
>>
>> Thanks ..But how do I tie the status worker to the list of nodes that
>> I have. For eg in below config how do I say that appfe1 is now
>> "stopped" and still keep servicing appfe2,3 and 4
>>
>>
>> worker.status.type=status
>> worker.tc.type=lb
>> worker.tc.balance_workers=appfe1,appfe2,appfe3,appfe4
>> worker.tc.sticky_session=true
>
> mount the worker named status to a URL, e.g.
>
> JkMount /mystatus status
>
> and then point your browser to this URL. It will show you a GUI, where you
> can edit the settings. E.g. there will be a block of data for the worker
> "tc", and there you can see a drop down list of attributes to edt. Choose
> activation then you get a page on which you can edit the activations of all
> members of "tc".
>
> See:
>
> http://tomcat.apache.org/connectors-doc/reference/status.html
>
> 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 not working as expected - is there a bug??
Posted by Rainer Jung <ra...@kippdata.de>.
On 06.03.2009 01:44, Mohit Anchlia wrote:
> Thanks ..But how do I tie the status worker to the list of nodes that
> I have. For eg in below config how do I say that appfe1 is now
> "stopped" and still keep servicing appfe2,3 and 4
>
>
> worker.status.type=status
> worker.tc.type=lb
> worker.tc.balance_workers=appfe1,appfe2,appfe3,appfe4
> worker.tc.sticky_session=true
mount the worker named status to a URL, e.g.
JkMount /mystatus status
and then point your browser to this URL. It will show you a GUI, where
you can edit the settings. E.g. there will be a block of data for the
worker "tc", and there you can see a drop down list of attributes to
edt. Choose activation then you get a page on which you can edit the
activations of all members of "tc".
See:
http://tomcat.apache.org/connectors-doc/reference/status.html
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
Thanks ..But how do I tie the status worker to the list of nodes that
I have. For eg in below config how do I say that appfe1 is now
"stopped" and still keep servicing appfe2,3 and 4
worker.status.type=status
worker.tc.type=lb
worker.tc.balance_workers=appfe1,appfe2,appfe3,appfe4
worker.tc.sticky_session=true
On Thu, Mar 5, 2009 at 4:07 PM, Rainer Jung <ra...@kippdata.de> wrote:
> On 05.03.2009 23:57, Mohit Anchlia wrote:
>>
>> So I tested again and it looks like Jboss accepts new connection when
>> it already undeployed the service. Do you have any advice of how I can
>> handle this scenario. I need to cleanly take that node out of service
>> from mod_jk with no customer impact. Is there anyway in apache to do
>> that so that it detects below scenario ..any possible way? Thanks for
>> your help.
>>
>> I see the following of http code 503:
>>
> ...
>
> Use the status worker and set the node to "stopped". All requests to the
> status worker are GET requests, so you can easily script/automate them.
>
> That's the cleanest way.
>
> 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 not working as expected - is there a bug??
Posted by Rainer Jung <ra...@kippdata.de>.
On 05.03.2009 23:57, Mohit Anchlia wrote:
> So I tested again and it looks like Jboss accepts new connection when
> it already undeployed the service. Do you have any advice of how I can
> handle this scenario. I need to cleanly take that node out of service
> from mod_jk with no customer impact. Is there anyway in apache to do
> that so that it detects below scenario ..any possible way? Thanks for
> your help.
>
> I see the following of http code 503:
>
...
Use the status worker and set the node to "stopped". All requests to the
status worker are GET requests, so you can easily script/automate them.
That's the cleanest way.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
So I tested again and it looks like Jboss accepts new connection when
it already undeployed the service. Do you have any advice of how I can
handle this scenario. I need to cleanly take that node out of service
from mod_jk with no customer impact. Is there anyway in apache to do
that so that it detects below scenario ..any possible way? Thanks for
your help.
I see the following of http code 503:
<html><head><title>JBossWeb/2.0.0.GA_CP01 - Error
report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;}
B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color :
#525D76;}--></style> </head><body><h1>HTTP Status 503 - This
application is not currently available</h1><HR size="1"
noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
<u>This application is not currently
available</u></p><p><b>description</b> <u>The requested service (This
application is not currently available) is not currently
available.</u></p><HR size="1"
noshade="noshade"><h3>JBossWeb/2.0.0.GA_CP01</h3></body></html>
On Mon, Mar 2, 2009 at 5:01 PM, Rainer Jung <ra...@kippdata.de> wrote:
> On 03.03.2009 01:45, Mohit Anchlia wrote:
>>
>> Is there a way to configure ping in workers.properties to also check
>> for 503 in addition to cping/cpong? I am sure you are going to laugh
>> at me.
>
> No I'm not laughing, but as I wrote, at the time Tomcat returns the cpong,
> there is no http status. There isn't yet a request.
>
> So this feature doesn't make sense.
>
> Regards,
>
> Rainer
>
>> On Mon, Mar 2, 2009 at 1:26 PM, Rainer Jung<ra...@kippdata.de>
>> wrote:
>>>
>>> On 02.03.2009 20:28, Mohit Anchlia wrote:
>>>>
>>>> I will change the JkLogLevel and post the results. I have a question
>>>> though: Does prepost_timeout also detect if it received http code such
>>>> as 503 from app server.
>>>
>>> prepost_timeout activates Cping/Cpong before each request. mod_jk will
>>> send
>>> a tiny test packet to the ap server before each request, and the AJP
>>> protocol stack of the app server will immediately respond with a tiny
>>> reply
>>> packet, indicating that it is still alive and able to parse AJP messages.
>>> The web application itself is not involved in this part of the
>>> processing,
>>> neither is any http request or response (or their AJP equivalent).
>>>
>>> So prepose_timeout will detect, if it receives some garbage (anything
>>> different from a Cpong packet), but http responses with http status codes
>>> are only generated much later and will thus not influence the prepose
>>> Cping/Cpong result.
>>>
>>> See also:
>>>
>>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>>>
>>> Regards,
>>>
>>> Rainer
>>>
>>>> On Wed, Feb 25, 2009 at 9:05 AM, Rainer Jung<ra...@kippdata.de>
>>>> wrote:
>>>>>
>>>>> On 25.02.2009 17:10, Mohit Anchlia wrote:
>>>>>>
>>>>>> you are right there is a mod-jk.conf. So given my workers.properties
>>>>>> file what should I change so that mod_jk detects that app server is
>>>>>> down before attempting to send the request. Shouldn't "retries" in
>>>>>> workers.properties try to connect to some other app server instead.
>>>>>
>>>>> Just a wild guess: your prepost timeout of 5 milliseconds produces the
>>>>> error
>>>>> messages you cited. First correct this timeout, then do another clean
>>>>> test
>>>>> on your test system. You can even increase JkLogLevel to trace (not in
>>>>> production) so we can see exactly what is going on. Do not send many
>>>>> requests with JkLogLevel trace, just do a minimal test that shows the
>>>>> problem.
>>>>>
>>>>> The early detection of a broken instance should be possible with your
>>>>> configuration.
>>>>>
>>>>>> Here is mod-jk.conf
>>>>>>
>>>>>> # Where to find workers.properties
>>>>>> JkWorkersFile conf/workers.properties
>>>>>>
>>>>>> # Where to put jk logs
>>>>>> JkLogFile /var/log/apache2/mod_jk.log
>>>>>>
>>>>>> # Set the jk log level [debug/error/info]
>>>>>> JkLogLevel error
>>>>>>
>>>>>> # Allow mod_jk worker status reports, with the URL of
>>>>>> http://servername/JkStatus
>>>>>> ## This is very helpful for monitoring purposes, but should be
>>>>>> ## allowed from the local machine.
>>>>>> <Location /JkStatus>
>>>>>> Order deny,allow
>>>>>> Deny from all
>>>>>> Allow from localhost
>>>>>> </Location>
>>>>>>
>>>>>> #JkMount /JkStatus status
>>>>>>
>>>>>> # Below line forward all requests to application server
>>>>>> #JkMount /* local
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung<ra...@kippdata.de>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 25.02.2009 02:47, Mohit Anchlia wrote:
>>>>>>>>
>>>>>>>> In httpd conf I just see JkMount and no other directive. I searched
>>>>>>>> for
>>>>>>>> Jk.
>>>>>>>
>>>>>>> There should be others as well, for instance JkWorkersFile to point
>>>>>>> to
>>>>>>> your
>>>>>>> workers.properties. The names of the directives are case insensitive,
>>>>>>> they
>>>>>>> can also be in files included to your main httpd configuration file
>>>>>>> via
>>>>>>> include directives.
>>>>>>>
>>>>>>>> Here is workers.properties file:
>>>>>>>
>>>>>>> ...
>>>>>>>>
>>>>>>>> # appfe1
>>>>>>>
>>>>>>> ...
>>>>>>>>
>>>>>>>> worker.appfe1.socket_timeout=5
>>>>>>>
>>>>>>> I generally don't like socket_timeout. Others do :)
>>>>>>>
>>>>>>>> worker.appfe1.prepost_timeout=5
>>>>>>>
>>>>>>> 5 milliseconds prepost timeout? You're kidding. I assume it should
>>>>>>> have
>>>>>>> been
>>>>>>> 5000.
>>>>>>>
>>>>>>>> worker.appfe1.recycle_timeout=900
>>>>>>>
>>>>>>> This is deprecated. Use connection_pool_timeout instead. The value is
>>>>>>> OK,
>>>>>>> you should set connectionTimeout on the Tomcat AJP connector to
>>>>>>> 900000
>>>>>>> then.
>>>>>>>
>>>>>>> Since you are using prefork MPM, you might want to set
>>>>>>> connection_pool_minsize to 0 if you want to keep the number of
>>>>>>> established
>>>>>>> connections low.
>>>>>>>
>>>>>>> And the same for the other members of the load balancer.
>>>>>>>
>>>>>>>> On Tue, Feb 24, 2009 at 4:50 PM, Rainer
>>>>>>>> Jung<ra...@kippdata.de>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On 25.02.2009 00:00, Mohit Anchlia wrote:
>>>>>>>>>>
>>>>>>>>>> Reposting:
>>>>>>>>>>
>>>>>>>>>> Apache Server - 2.2
>>>>>>>>>> Tomcat server 6
>>>>>>>>>> Jboss - 4.2
>>>>>>>>>>
>>>>>>>>>> We have Web Servers talking to Jboss App Servers over mod_jk. When
>>>>>>>>>> we
>>>>>>>>>> do our patch or upgrade of software we do it in rolling fashion so
>>>>>>>>>> that there is "0" customer impact. But it looks like mod_jk load
>>>>>>>>>> balancer on Web server doesn't detect it as soon as Jboss App
>>>>>>>>>> Server
>>>>>>>>>> goes down. Our goal is to have 0 customer impact. So my question
>>>>>>>>>> is
>>>>>>>>>> what can we do to overcome this problem. Web Server sees Http
>>>>>>>>>> Error
>>>>>>>>>> Code 503.
>>>>>>>>>>
>>>>>>>>>> Information from log file:
>>>>>>>>>>
>>>>>>>>>> [Mon Feb 23 13:39:42.146 2009] [31682:4143745888] [error]
>>>>>>>>>> ajp_connection_tcp_get_message::jk_ajp_common.c (966): (appfe4)
>>>>>>>>>> can't
>>>>>>>>>> receive the response message from tomcat, network problems or
>>>>>>>>>> tomcat
>>>>>>>>>> (10.10.81.89:8009) is down (errno=104)
>>>>>>>>>> [Mon Feb 23 13:39:42.147 2009] [31682:4143745888] [error]
>>>>>>>>>> ajp_service::jk_ajp_common.c (2097): (appfe4) Connecting to tomcat
>>>>>>>>>> failed. Tomcat is probably not started or is listening on the
>>>>>>>>>> wrong
>>>>>>>>>> port
>>>>>>>>>
>>>>>>>>> This means that mod_jk detected that your backend is down and thus
>>>>>>>>> puts
>>>>>>>>> it
>>>>>>>>> into an error state. All following requests will no longer be sent
>>>>>>>>> to
>>>>>>>>> this
>>>>>>>>> backend. Once a minute it will send a request there and try, but as
>>>>>>>>> long
>>>>>>>>> as
>>>>>>>>> it is down this test will not succeed and thus all requests will be
>>>>>>>>> sent
>>>>>>>>> to
>>>>>>>>> other nodes.
>>>>>>>>>
>>>>>>>>> The first request that gets sent to the backend you stopped might
>>>>>>>>> get
>>>>>>>>> an
>>>>>>>>> error back. If you want to prevent that from happening, use
>>>>>>>>> Cping/Cpong:
>>>>>>>>>
>>>>>>>>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>>>>>>>>>
>>>>>>>>> so we will detect the broken node before actually sending a request
>>>>>>>>> there.
>>>>>>>>> More details are not possible to give without your JK configuration
>>>>>>>>> (Jk
>>>>>>>>> directive sin httpd configuration files, workers.properties and if
>>>>>>>>> used
>>>>>>>>> uriworkermap.properties).
>>>>>>>>>
>>>>>>>>> The line number of the above message tells me you are using mod_jk
>>>>>>>>> 1.2.25.
>>>>>>>>> Although there's nothing wrong in principal with 1.2.25, we always
>>>>>>>>> try
>>>>>>>>> to
>>>>>>>>> improve and you might consider switching to 1.2.27.
>>>>>>>>>
>>>>>>>>> You should also increase your JkLogLevel to info. As long as only
>>>>>>>>> occasional
>>>>>>>>> info messages are in your log file everything is fine, but once
>>>>>>>>> error
>>>>>>>>> messages show up, the additional info messages contain useful
>>>>>>>>> formation.
>
> ---------------------------------------------------------------------
> 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 not working as expected - is there a bug??
Posted by Rainer Jung <ra...@kippdata.de>.
On 03.03.2009 01:45, Mohit Anchlia wrote:
> Is there a way to configure ping in workers.properties to also check
> for 503 in addition to cping/cpong? I am sure you are going to laugh
> at me.
No I'm not laughing, but as I wrote, at the time Tomcat returns the
cpong, there is no http status. There isn't yet a request.
So this feature doesn't make sense.
Regards,
Rainer
> On Mon, Mar 2, 2009 at 1:26 PM, Rainer Jung<ra...@kippdata.de> wrote:
>> On 02.03.2009 20:28, Mohit Anchlia wrote:
>>> I will change the JkLogLevel and post the results. I have a question
>>> though: Does prepost_timeout also detect if it received http code such
>>> as 503 from app server.
>> prepost_timeout activates Cping/Cpong before each request. mod_jk will send
>> a tiny test packet to the ap server before each request, and the AJP
>> protocol stack of the app server will immediately respond with a tiny reply
>> packet, indicating that it is still alive and able to parse AJP messages.
>> The web application itself is not involved in this part of the processing,
>> neither is any http request or response (or their AJP equivalent).
>>
>> So prepose_timeout will detect, if it receives some garbage (anything
>> different from a Cpong packet), but http responses with http status codes
>> are only generated much later and will thus not influence the prepose
>> Cping/Cpong result.
>>
>> See also:
>>
>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>>
>> Regards,
>>
>> Rainer
>>
>>> On Wed, Feb 25, 2009 at 9:05 AM, Rainer Jung<ra...@kippdata.de>
>>> wrote:
>>>> On 25.02.2009 17:10, Mohit Anchlia wrote:
>>>>> you are right there is a mod-jk.conf. So given my workers.properties
>>>>> file what should I change so that mod_jk detects that app server is
>>>>> down before attempting to send the request. Shouldn't "retries" in
>>>>> workers.properties try to connect to some other app server instead.
>>>> Just a wild guess: your prepost timeout of 5 milliseconds produces the
>>>> error
>>>> messages you cited. First correct this timeout, then do another clean
>>>> test
>>>> on your test system. You can even increase JkLogLevel to trace (not in
>>>> production) so we can see exactly what is going on. Do not send many
>>>> requests with JkLogLevel trace, just do a minimal test that shows the
>>>> problem.
>>>>
>>>> The early detection of a broken instance should be possible with your
>>>> configuration.
>>>>
>>>>> Here is mod-jk.conf
>>>>>
>>>>> # Where to find workers.properties
>>>>> JkWorkersFile conf/workers.properties
>>>>>
>>>>> # Where to put jk logs
>>>>> JkLogFile /var/log/apache2/mod_jk.log
>>>>>
>>>>> # Set the jk log level [debug/error/info]
>>>>> JkLogLevel error
>>>>>
>>>>> # Allow mod_jk worker status reports, with the URL of
>>>>> http://servername/JkStatus
>>>>> ## This is very helpful for monitoring purposes, but should be
>>>>> ## allowed from the local machine.
>>>>> <Location /JkStatus>
>>>>> Order deny,allow
>>>>> Deny from all
>>>>> Allow from localhost
>>>>> </Location>
>>>>>
>>>>> #JkMount /JkStatus status
>>>>>
>>>>> # Below line forward all requests to application server
>>>>> #JkMount /* local
>>>>>
>>>>>
>>>>> On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung<ra...@kippdata.de>
>>>>> wrote:
>>>>>> On 25.02.2009 02:47, Mohit Anchlia wrote:
>>>>>>> In httpd conf I just see JkMount and no other directive. I searched
>>>>>>> for
>>>>>>> Jk.
>>>>>> There should be others as well, for instance JkWorkersFile to point to
>>>>>> your
>>>>>> workers.properties. The names of the directives are case insensitive,
>>>>>> they
>>>>>> can also be in files included to your main httpd configuration file via
>>>>>> include directives.
>>>>>>
>>>>>>> Here is workers.properties file:
>>>>>> ...
>>>>>>> # appfe1
>>>>>> ...
>>>>>>> worker.appfe1.socket_timeout=5
>>>>>> I generally don't like socket_timeout. Others do :)
>>>>>>
>>>>>>> worker.appfe1.prepost_timeout=5
>>>>>> 5 milliseconds prepost timeout? You're kidding. I assume it should have
>>>>>> been
>>>>>> 5000.
>>>>>>
>>>>>>> worker.appfe1.recycle_timeout=900
>>>>>> This is deprecated. Use connection_pool_timeout instead. The value is
>>>>>> OK,
>>>>>> you should set connectionTimeout on the Tomcat AJP connector to 900000
>>>>>> then.
>>>>>>
>>>>>> Since you are using prefork MPM, you might want to set
>>>>>> connection_pool_minsize to 0 if you want to keep the number of
>>>>>> established
>>>>>> connections low.
>>>>>>
>>>>>> And the same for the other members of the load balancer.
>>>>>>
>>>>>>> On Tue, Feb 24, 2009 at 4:50 PM, Rainer Jung<ra...@kippdata.de>
>>>>>>> wrote:
>>>>>>>> On 25.02.2009 00:00, Mohit Anchlia wrote:
>>>>>>>>> Reposting:
>>>>>>>>>
>>>>>>>>> Apache Server - 2.2
>>>>>>>>> Tomcat server 6
>>>>>>>>> Jboss - 4.2
>>>>>>>>>
>>>>>>>>> We have Web Servers talking to Jboss App Servers over mod_jk. When
>>>>>>>>> we
>>>>>>>>> do our patch or upgrade of software we do it in rolling fashion so
>>>>>>>>> that there is "0" customer impact. But it looks like mod_jk load
>>>>>>>>> balancer on Web server doesn't detect it as soon as Jboss App Server
>>>>>>>>> goes down. Our goal is to have 0 customer impact. So my question is
>>>>>>>>> what can we do to overcome this problem. Web Server sees Http Error
>>>>>>>>> Code 503.
>>>>>>>>>
>>>>>>>>> Information from log file:
>>>>>>>>>
>>>>>>>>> [Mon Feb 23 13:39:42.146 2009] [31682:4143745888] [error]
>>>>>>>>> ajp_connection_tcp_get_message::jk_ajp_common.c (966): (appfe4)
>>>>>>>>> can't
>>>>>>>>> receive the response message from tomcat, network problems or tomcat
>>>>>>>>> (10.10.81.89:8009) is down (errno=104)
>>>>>>>>> [Mon Feb 23 13:39:42.147 2009] [31682:4143745888] [error]
>>>>>>>>> ajp_service::jk_ajp_common.c (2097): (appfe4) Connecting to tomcat
>>>>>>>>> failed. Tomcat is probably not started or is listening on the wrong
>>>>>>>>> port
>>>>>>>> This means that mod_jk detected that your backend is down and thus
>>>>>>>> puts
>>>>>>>> it
>>>>>>>> into an error state. All following requests will no longer be sent to
>>>>>>>> this
>>>>>>>> backend. Once a minute it will send a request there and try, but as
>>>>>>>> long
>>>>>>>> as
>>>>>>>> it is down this test will not succeed and thus all requests will be
>>>>>>>> sent
>>>>>>>> to
>>>>>>>> other nodes.
>>>>>>>>
>>>>>>>> The first request that gets sent to the backend you stopped might get
>>>>>>>> an
>>>>>>>> error back. If you want to prevent that from happening, use
>>>>>>>> Cping/Cpong:
>>>>>>>>
>>>>>>>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>>>>>>>>
>>>>>>>> so we will detect the broken node before actually sending a request
>>>>>>>> there.
>>>>>>>> More details are not possible to give without your JK configuration
>>>>>>>> (Jk
>>>>>>>> directive sin httpd configuration files, workers.properties and if
>>>>>>>> used
>>>>>>>> uriworkermap.properties).
>>>>>>>>
>>>>>>>> The line number of the above message tells me you are using mod_jk
>>>>>>>> 1.2.25.
>>>>>>>> Although there's nothing wrong in principal with 1.2.25, we always
>>>>>>>> try
>>>>>>>> to
>>>>>>>> improve and you might consider switching to 1.2.27.
>>>>>>>>
>>>>>>>> You should also increase your JkLogLevel to info. As long as only
>>>>>>>> occasional
>>>>>>>> info messages are in your log file everything is fine, but once error
>>>>>>>> messages show up, the additional info messages contain useful
>>>>>>>> formation.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
Is there a way to configure ping in workers.properties to also check
for 503 in addition to cping/cpong? I am sure you are going to laugh
at me.
On Mon, Mar 2, 2009 at 1:26 PM, Rainer Jung <ra...@kippdata.de> wrote:
> On 02.03.2009 20:28, Mohit Anchlia wrote:
>>
>> I will change the JkLogLevel and post the results. I have a question
>> though: Does prepost_timeout also detect if it received http code such
>> as 503 from app server.
>
> prepost_timeout activates Cping/Cpong before each request. mod_jk will send
> a tiny test packet to the ap server before each request, and the AJP
> protocol stack of the app server will immediately respond with a tiny reply
> packet, indicating that it is still alive and able to parse AJP messages.
> The web application itself is not involved in this part of the processing,
> neither is any http request or response (or their AJP equivalent).
>
> So prepose_timeout will detect, if it receives some garbage (anything
> different from a Cpong packet), but http responses with http status codes
> are only generated much later and will thus not influence the prepose
> Cping/Cpong result.
>
> See also:
>
> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>
> Regards,
>
> Rainer
>
>> On Wed, Feb 25, 2009 at 9:05 AM, Rainer Jung<ra...@kippdata.de>
>> wrote:
>>>
>>> On 25.02.2009 17:10, Mohit Anchlia wrote:
>>>>
>>>> you are right there is a mod-jk.conf. So given my workers.properties
>>>> file what should I change so that mod_jk detects that app server is
>>>> down before attempting to send the request. Shouldn't "retries" in
>>>> workers.properties try to connect to some other app server instead.
>>>
>>> Just a wild guess: your prepost timeout of 5 milliseconds produces the
>>> error
>>> messages you cited. First correct this timeout, then do another clean
>>> test
>>> on your test system. You can even increase JkLogLevel to trace (not in
>>> production) so we can see exactly what is going on. Do not send many
>>> requests with JkLogLevel trace, just do a minimal test that shows the
>>> problem.
>>>
>>> The early detection of a broken instance should be possible with your
>>> configuration.
>>>
>>>> Here is mod-jk.conf
>>>>
>>>> # Where to find workers.properties
>>>> JkWorkersFile conf/workers.properties
>>>>
>>>> # Where to put jk logs
>>>> JkLogFile /var/log/apache2/mod_jk.log
>>>>
>>>> # Set the jk log level [debug/error/info]
>>>> JkLogLevel error
>>>>
>>>> # Allow mod_jk worker status reports, with the URL of
>>>> http://servername/JkStatus
>>>> ## This is very helpful for monitoring purposes, but should be
>>>> ## allowed from the local machine.
>>>> <Location /JkStatus>
>>>> Order deny,allow
>>>> Deny from all
>>>> Allow from localhost
>>>> </Location>
>>>>
>>>> #JkMount /JkStatus status
>>>>
>>>> # Below line forward all requests to application server
>>>> #JkMount /* local
>>>>
>>>>
>>>> On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung<ra...@kippdata.de>
>>>> wrote:
>>>>>
>>>>> On 25.02.2009 02:47, Mohit Anchlia wrote:
>>>>>>
>>>>>> In httpd conf I just see JkMount and no other directive. I searched
>>>>>> for
>>>>>> Jk.
>>>>>
>>>>> There should be others as well, for instance JkWorkersFile to point to
>>>>> your
>>>>> workers.properties. The names of the directives are case insensitive,
>>>>> they
>>>>> can also be in files included to your main httpd configuration file via
>>>>> include directives.
>>>>>
>>>>>> Here is workers.properties file:
>>>>>
>>>>> ...
>>>>>>
>>>>>> # appfe1
>>>>>
>>>>> ...
>>>>>>
>>>>>> worker.appfe1.socket_timeout=5
>>>>>
>>>>> I generally don't like socket_timeout. Others do :)
>>>>>
>>>>>> worker.appfe1.prepost_timeout=5
>>>>>
>>>>> 5 milliseconds prepost timeout? You're kidding. I assume it should have
>>>>> been
>>>>> 5000.
>>>>>
>>>>>> worker.appfe1.recycle_timeout=900
>>>>>
>>>>> This is deprecated. Use connection_pool_timeout instead. The value is
>>>>> OK,
>>>>> you should set connectionTimeout on the Tomcat AJP connector to 900000
>>>>> then.
>>>>>
>>>>> Since you are using prefork MPM, you might want to set
>>>>> connection_pool_minsize to 0 if you want to keep the number of
>>>>> established
>>>>> connections low.
>>>>>
>>>>> And the same for the other members of the load balancer.
>>>>>
>>>>>> On Tue, Feb 24, 2009 at 4:50 PM, Rainer Jung<ra...@kippdata.de>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 25.02.2009 00:00, Mohit Anchlia wrote:
>>>>>>>>
>>>>>>>> Reposting:
>>>>>>>>
>>>>>>>> Apache Server - 2.2
>>>>>>>> Tomcat server 6
>>>>>>>> Jboss - 4.2
>>>>>>>>
>>>>>>>> We have Web Servers talking to Jboss App Servers over mod_jk. When
>>>>>>>> we
>>>>>>>> do our patch or upgrade of software we do it in rolling fashion so
>>>>>>>> that there is "0" customer impact. But it looks like mod_jk load
>>>>>>>> balancer on Web server doesn't detect it as soon as Jboss App Server
>>>>>>>> goes down. Our goal is to have 0 customer impact. So my question is
>>>>>>>> what can we do to overcome this problem. Web Server sees Http Error
>>>>>>>> Code 503.
>>>>>>>>
>>>>>>>> Information from log file:
>>>>>>>>
>>>>>>>> [Mon Feb 23 13:39:42.146 2009] [31682:4143745888] [error]
>>>>>>>> ajp_connection_tcp_get_message::jk_ajp_common.c (966): (appfe4)
>>>>>>>> can't
>>>>>>>> receive the response message from tomcat, network problems or tomcat
>>>>>>>> (10.10.81.89:8009) is down (errno=104)
>>>>>>>> [Mon Feb 23 13:39:42.147 2009] [31682:4143745888] [error]
>>>>>>>> ajp_service::jk_ajp_common.c (2097): (appfe4) Connecting to tomcat
>>>>>>>> failed. Tomcat is probably not started or is listening on the wrong
>>>>>>>> port
>>>>>>>
>>>>>>> This means that mod_jk detected that your backend is down and thus
>>>>>>> puts
>>>>>>> it
>>>>>>> into an error state. All following requests will no longer be sent to
>>>>>>> this
>>>>>>> backend. Once a minute it will send a request there and try, but as
>>>>>>> long
>>>>>>> as
>>>>>>> it is down this test will not succeed and thus all requests will be
>>>>>>> sent
>>>>>>> to
>>>>>>> other nodes.
>>>>>>>
>>>>>>> The first request that gets sent to the backend you stopped might get
>>>>>>> an
>>>>>>> error back. If you want to prevent that from happening, use
>>>>>>> Cping/Cpong:
>>>>>>>
>>>>>>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>>>>>>>
>>>>>>> so we will detect the broken node before actually sending a request
>>>>>>> there.
>>>>>>> More details are not possible to give without your JK configuration
>>>>>>> (Jk
>>>>>>> directive sin httpd configuration files, workers.properties and if
>>>>>>> used
>>>>>>> uriworkermap.properties).
>>>>>>>
>>>>>>> The line number of the above message tells me you are using mod_jk
>>>>>>> 1.2.25.
>>>>>>> Although there's nothing wrong in principal with 1.2.25, we always
>>>>>>> try
>>>>>>> to
>>>>>>> improve and you might consider switching to 1.2.27.
>>>>>>>
>>>>>>> You should also increase your JkLogLevel to info. As long as only
>>>>>>> occasional
>>>>>>> info messages are in your log file everything is fine, but once error
>>>>>>> messages show up, the additional info messages contain useful
>>>>>>> formation.
>>>>>>>
>>>>>>> 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 not working as expected - is there a bug??
Posted by Rainer Jung <ra...@kippdata.de>.
On 02.03.2009 20:28, Mohit Anchlia wrote:
> I will change the JkLogLevel and post the results. I have a question
> though: Does prepost_timeout also detect if it received http code such
> as 503 from app server.
prepost_timeout activates Cping/Cpong before each request. mod_jk will
send a tiny test packet to the ap server before each request, and the
AJP protocol stack of the app server will immediately respond with a
tiny reply packet, indicating that it is still alive and able to parse
AJP messages. The web application itself is not involved in this part of
the processing, neither is any http request or response (or their AJP
equivalent).
So prepose_timeout will detect, if it receives some garbage (anything
different from a Cpong packet), but http responses with http status
codes are only generated much later and will thus not influence the
prepose Cping/Cpong result.
See also:
http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
Regards,
Rainer
> On Wed, Feb 25, 2009 at 9:05 AM, Rainer Jung<ra...@kippdata.de> wrote:
>> On 25.02.2009 17:10, Mohit Anchlia wrote:
>>> you are right there is a mod-jk.conf. So given my workers.properties
>>> file what should I change so that mod_jk detects that app server is
>>> down before attempting to send the request. Shouldn't "retries" in
>>> workers.properties try to connect to some other app server instead.
>> Just a wild guess: your prepost timeout of 5 milliseconds produces the error
>> messages you cited. First correct this timeout, then do another clean test
>> on your test system. You can even increase JkLogLevel to trace (not in
>> production) so we can see exactly what is going on. Do not send many
>> requests with JkLogLevel trace, just do a minimal test that shows the
>> problem.
>>
>> The early detection of a broken instance should be possible with your
>> configuration.
>>
>>> Here is mod-jk.conf
>>>
>>> # Where to find workers.properties
>>> JkWorkersFile conf/workers.properties
>>>
>>> # Where to put jk logs
>>> JkLogFile /var/log/apache2/mod_jk.log
>>>
>>> # Set the jk log level [debug/error/info]
>>> JkLogLevel error
>>>
>>> # Allow mod_jk worker status reports, with the URL of
>>> http://servername/JkStatus
>>> ## This is very helpful for monitoring purposes, but should be
>>> ## allowed from the local machine.
>>> <Location /JkStatus>
>>> Order deny,allow
>>> Deny from all
>>> Allow from localhost
>>> </Location>
>>>
>>> #JkMount /JkStatus status
>>>
>>> # Below line forward all requests to application server
>>> #JkMount /* local
>>>
>>>
>>> On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung<ra...@kippdata.de>
>>> wrote:
>>>> On 25.02.2009 02:47, Mohit Anchlia wrote:
>>>>> In httpd conf I just see JkMount and no other directive. I searched for
>>>>> Jk.
>>>> There should be others as well, for instance JkWorkersFile to point to
>>>> your
>>>> workers.properties. The names of the directives are case insensitive,
>>>> they
>>>> can also be in files included to your main httpd configuration file via
>>>> include directives.
>>>>
>>>>> Here is workers.properties file:
>>>> ...
>>>>> # appfe1
>>>> ...
>>>>> worker.appfe1.socket_timeout=5
>>>> I generally don't like socket_timeout. Others do :)
>>>>
>>>>> worker.appfe1.prepost_timeout=5
>>>> 5 milliseconds prepost timeout? You're kidding. I assume it should have
>>>> been
>>>> 5000.
>>>>
>>>>> worker.appfe1.recycle_timeout=900
>>>> This is deprecated. Use connection_pool_timeout instead. The value is OK,
>>>> you should set connectionTimeout on the Tomcat AJP connector to 900000
>>>> then.
>>>>
>>>> Since you are using prefork MPM, you might want to set
>>>> connection_pool_minsize to 0 if you want to keep the number of
>>>> established
>>>> connections low.
>>>>
>>>> And the same for the other members of the load balancer.
>>>>
>>>>> On Tue, Feb 24, 2009 at 4:50 PM, Rainer Jung<ra...@kippdata.de>
>>>>> wrote:
>>>>>> On 25.02.2009 00:00, Mohit Anchlia wrote:
>>>>>>> Reposting:
>>>>>>>
>>>>>>> Apache Server - 2.2
>>>>>>> Tomcat server 6
>>>>>>> Jboss - 4.2
>>>>>>>
>>>>>>> We have Web Servers talking to Jboss App Servers over mod_jk. When we
>>>>>>> do our patch or upgrade of software we do it in rolling fashion so
>>>>>>> that there is "0" customer impact. But it looks like mod_jk load
>>>>>>> balancer on Web server doesn't detect it as soon as Jboss App Server
>>>>>>> goes down. Our goal is to have 0 customer impact. So my question is
>>>>>>> what can we do to overcome this problem. Web Server sees Http Error
>>>>>>> Code 503.
>>>>>>>
>>>>>>> Information from log file:
>>>>>>>
>>>>>>> [Mon Feb 23 13:39:42.146 2009] [31682:4143745888] [error]
>>>>>>> ajp_connection_tcp_get_message::jk_ajp_common.c (966): (appfe4) can't
>>>>>>> receive the response message from tomcat, network problems or tomcat
>>>>>>> (10.10.81.89:8009) is down (errno=104)
>>>>>>> [Mon Feb 23 13:39:42.147 2009] [31682:4143745888] [error]
>>>>>>> ajp_service::jk_ajp_common.c (2097): (appfe4) Connecting to tomcat
>>>>>>> failed. Tomcat is probably not started or is listening on the wrong
>>>>>>> port
>>>>>> This means that mod_jk detected that your backend is down and thus puts
>>>>>> it
>>>>>> into an error state. All following requests will no longer be sent to
>>>>>> this
>>>>>> backend. Once a minute it will send a request there and try, but as
>>>>>> long
>>>>>> as
>>>>>> it is down this test will not succeed and thus all requests will be
>>>>>> sent
>>>>>> to
>>>>>> other nodes.
>>>>>>
>>>>>> The first request that gets sent to the backend you stopped might get
>>>>>> an
>>>>>> error back. If you want to prevent that from happening, use
>>>>>> Cping/Cpong:
>>>>>>
>>>>>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>>>>>>
>>>>>> so we will detect the broken node before actually sending a request
>>>>>> there.
>>>>>> More details are not possible to give without your JK configuration (Jk
>>>>>> directive sin httpd configuration files, workers.properties and if used
>>>>>> uriworkermap.properties).
>>>>>>
>>>>>> The line number of the above message tells me you are using mod_jk
>>>>>> 1.2.25.
>>>>>> Although there's nothing wrong in principal with 1.2.25, we always try
>>>>>> to
>>>>>> improve and you might consider switching to 1.2.27.
>>>>>>
>>>>>> You should also increase your JkLogLevel to info. As long as only
>>>>>> occasional
>>>>>> info messages are in your log file everything is fine, but once error
>>>>>> messages show up, the additional info messages contain useful
>>>>>> formation.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
I will change the JkLogLevel and post the results. I have a question
though: Does prepost_timeout also detect if it received http code such
as 503 from app server.
On Wed, Feb 25, 2009 at 9:05 AM, Rainer Jung <ra...@kippdata.de> wrote:
> On 25.02.2009 17:10, Mohit Anchlia wrote:
>>
>> you are right there is a mod-jk.conf. So given my workers.properties
>> file what should I change so that mod_jk detects that app server is
>> down before attempting to send the request. Shouldn't "retries" in
>> workers.properties try to connect to some other app server instead.
>
> Just a wild guess: your prepost timeout of 5 milliseconds produces the error
> messages you cited. First correct this timeout, then do another clean test
> on your test system. You can even increase JkLogLevel to trace (not in
> production) so we can see exactly what is going on. Do not send many
> requests with JkLogLevel trace, just do a minimal test that shows the
> problem.
>
> The early detection of a broken instance should be possible with your
> configuration.
>
>> Here is mod-jk.conf
>>
>> # Where to find workers.properties
>> JkWorkersFile conf/workers.properties
>>
>> # Where to put jk logs
>> JkLogFile /var/log/apache2/mod_jk.log
>>
>> # Set the jk log level [debug/error/info]
>> JkLogLevel error
>>
>> # Allow mod_jk worker status reports, with the URL of
>> http://servername/JkStatus
>> ## This is very helpful for monitoring purposes, but should be
>> ## allowed from the local machine.
>> <Location /JkStatus>
>> Order deny,allow
>> Deny from all
>> Allow from localhost
>> </Location>
>>
>> #JkMount /JkStatus status
>>
>> # Below line forward all requests to application server
>> #JkMount /* local
>>
>>
>> On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung<ra...@kippdata.de>
>> wrote:
>>>
>>> On 25.02.2009 02:47, Mohit Anchlia wrote:
>>>>
>>>> In httpd conf I just see JkMount and no other directive. I searched for
>>>> Jk.
>>>
>>> There should be others as well, for instance JkWorkersFile to point to
>>> your
>>> workers.properties. The names of the directives are case insensitive,
>>> they
>>> can also be in files included to your main httpd configuration file via
>>> include directives.
>>>
>>>> Here is workers.properties file:
>>>
>>> ...
>>>>
>>>> # appfe1
>>>
>>> ...
>>>>
>>>> worker.appfe1.socket_timeout=5
>>>
>>> I generally don't like socket_timeout. Others do :)
>>>
>>>> worker.appfe1.prepost_timeout=5
>>>
>>> 5 milliseconds prepost timeout? You're kidding. I assume it should have
>>> been
>>> 5000.
>>>
>>>> worker.appfe1.recycle_timeout=900
>>>
>>> This is deprecated. Use connection_pool_timeout instead. The value is OK,
>>> you should set connectionTimeout on the Tomcat AJP connector to 900000
>>> then.
>>>
>>> Since you are using prefork MPM, you might want to set
>>> connection_pool_minsize to 0 if you want to keep the number of
>>> established
>>> connections low.
>>>
>>> And the same for the other members of the load balancer.
>>>
>>>> On Tue, Feb 24, 2009 at 4:50 PM, Rainer Jung<ra...@kippdata.de>
>>>> wrote:
>>>>>
>>>>> On 25.02.2009 00:00, Mohit Anchlia wrote:
>>>>>>
>>>>>> Reposting:
>>>>>>
>>>>>> Apache Server - 2.2
>>>>>> Tomcat server 6
>>>>>> Jboss - 4.2
>>>>>>
>>>>>> We have Web Servers talking to Jboss App Servers over mod_jk. When we
>>>>>> do our patch or upgrade of software we do it in rolling fashion so
>>>>>> that there is "0" customer impact. But it looks like mod_jk load
>>>>>> balancer on Web server doesn't detect it as soon as Jboss App Server
>>>>>> goes down. Our goal is to have 0 customer impact. So my question is
>>>>>> what can we do to overcome this problem. Web Server sees Http Error
>>>>>> Code 503.
>>>>>>
>>>>>> Information from log file:
>>>>>>
>>>>>> [Mon Feb 23 13:39:42.146 2009] [31682:4143745888] [error]
>>>>>> ajp_connection_tcp_get_message::jk_ajp_common.c (966): (appfe4) can't
>>>>>> receive the response message from tomcat, network problems or tomcat
>>>>>> (10.10.81.89:8009) is down (errno=104)
>>>>>> [Mon Feb 23 13:39:42.147 2009] [31682:4143745888] [error]
>>>>>> ajp_service::jk_ajp_common.c (2097): (appfe4) Connecting to tomcat
>>>>>> failed. Tomcat is probably not started or is listening on the wrong
>>>>>> port
>>>>>
>>>>> This means that mod_jk detected that your backend is down and thus puts
>>>>> it
>>>>> into an error state. All following requests will no longer be sent to
>>>>> this
>>>>> backend. Once a minute it will send a request there and try, but as
>>>>> long
>>>>> as
>>>>> it is down this test will not succeed and thus all requests will be
>>>>> sent
>>>>> to
>>>>> other nodes.
>>>>>
>>>>> The first request that gets sent to the backend you stopped might get
>>>>> an
>>>>> error back. If you want to prevent that from happening, use
>>>>> Cping/Cpong:
>>>>>
>>>>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>>>>>
>>>>> so we will detect the broken node before actually sending a request
>>>>> there.
>>>>> More details are not possible to give without your JK configuration (Jk
>>>>> directive sin httpd configuration files, workers.properties and if used
>>>>> uriworkermap.properties).
>>>>>
>>>>> The line number of the above message tells me you are using mod_jk
>>>>> 1.2.25.
>>>>> Although there's nothing wrong in principal with 1.2.25, we always try
>>>>> to
>>>>> improve and you might consider switching to 1.2.27.
>>>>>
>>>>> You should also increase your JkLogLevel to info. As long as only
>>>>> occasional
>>>>> info messages are in your log file everything is fine, but once error
>>>>> messages show up, the additional info messages contain useful
>>>>> formation.
>>>>>
>>>>> 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 not working as expected - is there a bug??
Posted by Rainer Jung <ra...@kippdata.de>.
On 25.02.2009 17:10, Mohit Anchlia wrote:
> you are right there is a mod-jk.conf. So given my workers.properties
> file what should I change so that mod_jk detects that app server is
> down before attempting to send the request. Shouldn't "retries" in
> workers.properties try to connect to some other app server instead.
Just a wild guess: your prepost timeout of 5 milliseconds produces the
error messages you cited. First correct this timeout, then do another
clean test on your test system. You can even increase JkLogLevel to
trace (not in production) so we can see exactly what is going on. Do not
send many requests with JkLogLevel trace, just do a minimal test that
shows the problem.
The early detection of a broken instance should be possible with your
configuration.
> Here is mod-jk.conf
>
> # Where to find workers.properties
> JkWorkersFile conf/workers.properties
>
> # Where to put jk logs
> JkLogFile /var/log/apache2/mod_jk.log
>
> # Set the jk log level [debug/error/info]
> JkLogLevel error
>
> # Allow mod_jk worker status reports, with the URL of http://servername/JkStatus
> ## This is very helpful for monitoring purposes, but should be
> ## allowed from the local machine.
> <Location /JkStatus>
> Order deny,allow
> Deny from all
> Allow from localhost
> </Location>
>
> #JkMount /JkStatus status
>
> # Below line forward all requests to application server
> #JkMount /* local
>
>
> On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung<ra...@kippdata.de> wrote:
>> On 25.02.2009 02:47, Mohit Anchlia wrote:
>>> In httpd conf I just see JkMount and no other directive. I searched for
>>> Jk.
>> There should be others as well, for instance JkWorkersFile to point to your
>> workers.properties. The names of the directives are case insensitive, they
>> can also be in files included to your main httpd configuration file via
>> include directives.
>>
>>> Here is workers.properties file:
>> ...
>>> # appfe1
>> ...
>>> worker.appfe1.socket_timeout=5
>> I generally don't like socket_timeout. Others do :)
>>
>>> worker.appfe1.prepost_timeout=5
>> 5 milliseconds prepost timeout? You're kidding. I assume it should have been
>> 5000.
>>
>>> worker.appfe1.recycle_timeout=900
>> This is deprecated. Use connection_pool_timeout instead. The value is OK,
>> you should set connectionTimeout on the Tomcat AJP connector to 900000 then.
>>
>> Since you are using prefork MPM, you might want to set
>> connection_pool_minsize to 0 if you want to keep the number of established
>> connections low.
>>
>> And the same for the other members of the load balancer.
>>
>>> On Tue, Feb 24, 2009 at 4:50 PM, Rainer Jung<ra...@kippdata.de>
>>> wrote:
>>>> On 25.02.2009 00:00, Mohit Anchlia wrote:
>>>>> Reposting:
>>>>>
>>>>> Apache Server - 2.2
>>>>> Tomcat server 6
>>>>> Jboss - 4.2
>>>>>
>>>>> We have Web Servers talking to Jboss App Servers over mod_jk. When we
>>>>> do our patch or upgrade of software we do it in rolling fashion so
>>>>> that there is "0" customer impact. But it looks like mod_jk load
>>>>> balancer on Web server doesn't detect it as soon as Jboss App Server
>>>>> goes down. Our goal is to have 0 customer impact. So my question is
>>>>> what can we do to overcome this problem. Web Server sees Http Error
>>>>> Code 503.
>>>>>
>>>>> Information from log file:
>>>>>
>>>>> [Mon Feb 23 13:39:42.146 2009] [31682:4143745888] [error]
>>>>> ajp_connection_tcp_get_message::jk_ajp_common.c (966): (appfe4) can't
>>>>> receive the response message from tomcat, network problems or tomcat
>>>>> (10.10.81.89:8009) is down (errno=104)
>>>>> [Mon Feb 23 13:39:42.147 2009] [31682:4143745888] [error]
>>>>> ajp_service::jk_ajp_common.c (2097): (appfe4) Connecting to tomcat
>>>>> failed. Tomcat is probably not started or is listening on the wrong
>>>>> port
>>>> This means that mod_jk detected that your backend is down and thus puts
>>>> it
>>>> into an error state. All following requests will no longer be sent to
>>>> this
>>>> backend. Once a minute it will send a request there and try, but as long
>>>> as
>>>> it is down this test will not succeed and thus all requests will be sent
>>>> to
>>>> other nodes.
>>>>
>>>> The first request that gets sent to the backend you stopped might get an
>>>> error back. If you want to prevent that from happening, use Cping/Cpong:
>>>>
>>>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>>>>
>>>> so we will detect the broken node before actually sending a request
>>>> there.
>>>> More details are not possible to give without your JK configuration (Jk
>>>> directive sin httpd configuration files, workers.properties and if used
>>>> uriworkermap.properties).
>>>>
>>>> The line number of the above message tells me you are using mod_jk
>>>> 1.2.25.
>>>> Although there's nothing wrong in principal with 1.2.25, we always try to
>>>> improve and you might consider switching to 1.2.27.
>>>>
>>>> You should also increase your JkLogLevel to info. As long as only
>>>> occasional
>>>> info messages are in your log file everything is fine, but once error
>>>> messages show up, the additional info messages contain useful formation.
>>>>
>>>> Regards,
>>>>
>>>> Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
you are right there is a mod-jk.conf. So given my workers.properties
file what should I change so that mod_jk detects that app server is
down before attempting to send the request. Shouldn't "retries" in
workers.properties try to connect to some other app server instead.
Here is mod-jk.conf
# Where to find workers.properties
JkWorkersFile conf/workers.properties
# Where to put jk logs
JkLogFile /var/log/apache2/mod_jk.log
# Set the jk log level [debug/error/info]
JkLogLevel error
# Allow mod_jk worker status reports, with the URL of http://servername/JkStatus
## This is very helpful for monitoring purposes, but should be
## allowed from the local machine.
<Location /JkStatus>
Order deny,allow
Deny from all
Allow from localhost
</Location>
#JkMount /JkStatus status
# Below line forward all requests to application server
#JkMount /* local
On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung <ra...@kippdata.de> wrote:
> On 25.02.2009 02:47, Mohit Anchlia wrote:
>>
>> In httpd conf I just see JkMount and no other directive. I searched for
>> Jk.
>
> There should be others as well, for instance JkWorkersFile to point to your
> workers.properties. The names of the directives are case insensitive, they
> can also be in files included to your main httpd configuration file via
> include directives.
>
>> Here is workers.properties file:
>
> ...
>>
>> # appfe1
>
> ...
>>
>> worker.appfe1.socket_timeout=5
>
> I generally don't like socket_timeout. Others do :)
>
>> worker.appfe1.prepost_timeout=5
>
> 5 milliseconds prepost timeout? You're kidding. I assume it should have been
> 5000.
>
>> worker.appfe1.recycle_timeout=900
>
> This is deprecated. Use connection_pool_timeout instead. The value is OK,
> you should set connectionTimeout on the Tomcat AJP connector to 900000 then.
>
> Since you are using prefork MPM, you might want to set
> connection_pool_minsize to 0 if you want to keep the number of established
> connections low.
>
> And the same for the other members of the load balancer.
>
>> On Tue, Feb 24, 2009 at 4:50 PM, Rainer Jung<ra...@kippdata.de>
>> wrote:
>>>
>>> On 25.02.2009 00:00, Mohit Anchlia wrote:
>>>>
>>>> Reposting:
>>>>
>>>> Apache Server - 2.2
>>>> Tomcat server 6
>>>> Jboss - 4.2
>>>>
>>>> We have Web Servers talking to Jboss App Servers over mod_jk. When we
>>>> do our patch or upgrade of software we do it in rolling fashion so
>>>> that there is "0" customer impact. But it looks like mod_jk load
>>>> balancer on Web server doesn't detect it as soon as Jboss App Server
>>>> goes down. Our goal is to have 0 customer impact. So my question is
>>>> what can we do to overcome this problem. Web Server sees Http Error
>>>> Code 503.
>>>>
>>>> Information from log file:
>>>>
>>>> [Mon Feb 23 13:39:42.146 2009] [31682:4143745888] [error]
>>>> ajp_connection_tcp_get_message::jk_ajp_common.c (966): (appfe4) can't
>>>> receive the response message from tomcat, network problems or tomcat
>>>> (10.10.81.89:8009) is down (errno=104)
>>>> [Mon Feb 23 13:39:42.147 2009] [31682:4143745888] [error]
>>>> ajp_service::jk_ajp_common.c (2097): (appfe4) Connecting to tomcat
>>>> failed. Tomcat is probably not started or is listening on the wrong
>>>> port
>>>
>>> This means that mod_jk detected that your backend is down and thus puts
>>> it
>>> into an error state. All following requests will no longer be sent to
>>> this
>>> backend. Once a minute it will send a request there and try, but as long
>>> as
>>> it is down this test will not succeed and thus all requests will be sent
>>> to
>>> other nodes.
>>>
>>> The first request that gets sent to the backend you stopped might get an
>>> error back. If you want to prevent that from happening, use Cping/Cpong:
>>>
>>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>>>
>>> so we will detect the broken node before actually sending a request
>>> there.
>>> More details are not possible to give without your JK configuration (Jk
>>> directive sin httpd configuration files, workers.properties and if used
>>> uriworkermap.properties).
>>>
>>> The line number of the above message tells me you are using mod_jk
>>> 1.2.25.
>>> Although there's nothing wrong in principal with 1.2.25, we always try to
>>> improve and you might consider switching to 1.2.27.
>>>
>>> You should also increase your JkLogLevel to info. As long as only
>>> occasional
>>> info messages are in your log file everything is fine, but once error
>>> messages show up, the additional info messages contain useful formation.
>>>
>>> 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 not working as expected - is there a bug??
Posted by Rainer Jung <ra...@kippdata.de>.
On 25.02.2009 02:47, Mohit Anchlia wrote:
> In httpd conf I just see JkMount and no other directive. I searched for Jk.
There should be others as well, for instance JkWorkersFile to point to
your workers.properties. The names of the directives are case
insensitive, they can also be in files included to your main httpd
configuration file via include directives.
> Here is workers.properties file:
...
> # appfe1
...
> worker.appfe1.socket_timeout=5
I generally don't like socket_timeout. Others do :)
> worker.appfe1.prepost_timeout=5
5 milliseconds prepost timeout? You're kidding. I assume it should have
been 5000.
> worker.appfe1.recycle_timeout=900
This is deprecated. Use connection_pool_timeout instead. The value is
OK, you should set connectionTimeout on the Tomcat AJP connector to
900000 then.
Since you are using prefork MPM, you might want to set
connection_pool_minsize to 0 if you want to keep the number of
established connections low.
And the same for the other members of the load balancer.
> On Tue, Feb 24, 2009 at 4:50 PM, Rainer Jung<ra...@kippdata.de> wrote:
>> On 25.02.2009 00:00, Mohit Anchlia wrote:
>>> Reposting:
>>>
>>> Apache Server - 2.2
>>> Tomcat server 6
>>> Jboss - 4.2
>>>
>>> We have Web Servers talking to Jboss App Servers over mod_jk. When we
>>> do our patch or upgrade of software we do it in rolling fashion so
>>> that there is "0" customer impact. But it looks like mod_jk load
>>> balancer on Web server doesn't detect it as soon as Jboss App Server
>>> goes down. Our goal is to have 0 customer impact. So my question is
>>> what can we do to overcome this problem. Web Server sees Http Error
>>> Code 503.
>>>
>>> Information from log file:
>>>
>>> [Mon Feb 23 13:39:42.146 2009] [31682:4143745888] [error]
>>> ajp_connection_tcp_get_message::jk_ajp_common.c (966): (appfe4) can't
>>> receive the response message from tomcat, network problems or tomcat
>>> (10.10.81.89:8009) is down (errno=104)
>>> [Mon Feb 23 13:39:42.147 2009] [31682:4143745888] [error]
>>> ajp_service::jk_ajp_common.c (2097): (appfe4) Connecting to tomcat
>>> failed. Tomcat is probably not started or is listening on the wrong
>>> port
>> This means that mod_jk detected that your backend is down and thus puts it
>> into an error state. All following requests will no longer be sent to this
>> backend. Once a minute it will send a request there and try, but as long as
>> it is down this test will not succeed and thus all requests will be sent to
>> other nodes.
>>
>> The first request that gets sent to the backend you stopped might get an
>> error back. If you want to prevent that from happening, use Cping/Cpong:
>>
>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>>
>> so we will detect the broken node before actually sending a request there.
>> More details are not possible to give without your JK configuration (Jk
>> directive sin httpd configuration files, workers.properties and if used
>> uriworkermap.properties).
>>
>> The line number of the above message tells me you are using mod_jk 1.2.25.
>> Although there's nothing wrong in principal with 1.2.25, we always try to
>> improve and you might consider switching to 1.2.27.
>>
>> You should also increase your JkLogLevel to info. As long as only occasional
>> info messages are in your log file everything is fine, but once error
>> messages show up, the additional info messages contain useful formation.
>>
>> Regards,
>>
>> Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
Posted by Mohit Anchlia <mo...@gmail.com>.
In httpd conf I just see JkMount and no other directive. I searched for Jk.
Here is workers.properties file:
##
worker.list=status,tc
## Worker Configuration##
# All entries in this section take the form:
# worker.<workername>.<directive>=<value>
# Worker names are defined in the worker.list directive above.
# Configuration specifying the worker named "status" as a status worker.
# This worker can be used to administer the other configured workers.
worker.status.type=status
# Configuration for the default load balancer worker.
# Uncomment the configuration for the "tc"
# worker, and the two "node" workers below to enable.
# Also add "lb" to the workers.list directive
# above. The default for the load balancer worker is
# round-robin distribution of requests over
# all active nodes. There are currently two nodes set
# up for the load balanced worker, add more
# to this list if required. Sticky sessions is defaulted to true.
worker.tc.type=lb
worker.tc.balance_workers=appfe1,appfe2,appfe3,appfe4
worker.tc.sticky_session=true
# Two load balanced workers, called node1 and node2.
# Copy the configurations and add to the
# worker.tc.balanced_workers
# list above to add more nodes to the Tomcat cluster.
# appfe1
worker.appfe1.type=ajp13
worker.appfe1.port=8009
worker.appfe1.host=appfe1
worker.appfe1.socket_timeout=5
worker.appfe1.socket_keepalive=true
worker.appfe1.prepost_timeout=5
worker.appfe1.connect_timeout=5000
worker.appfe1.retries=3
worker.appfe1.recycle_timeout=900
# Refererence BHP Apache tuning guide before uncomment the following
line. The unit of reply_timeout is millisecond.
#worker.appfe1.reply_timeout=0
# appfe2
worker.appfe2.type=ajp13
worker.appfe2.port=8009
worker.appfe2.host=appfe2
worker.appfe2.socket_timeout=5
worker.appfe2.socket_keepalive=true
worker.appfe2.prepost_timeout=5
worker.appfe2.connect_timeout=5000
worker.appfe2.retries=3
worker.appfe2.recycle_timeout=900
# Refererence BHP Apache tuning guide before uncomment the following
line. The unit of reply_timeout is millisecond.
#worker.appfe2.reply_timeout=0
# appfe3
worker.appfe3.type=ajp13
worker.appfe3.port=8009
worker.appfe3.host=appfe3
worker.appfe3.socket_timeout=5
worker.appfe3.socket_keepalive=true
worker.appfe3.prepost_timeout=5
worker.appfe3.connect_timeout=5000
worker.appfe3.retries=3
worker.appfe3.recycle_timeout=900
# Refererence BHP Apache tuning guide before uncomment the following
line. The unit of reply_timeout is millisecond.
#worker.appfe3.reply_timeout=0
# appfe4
worker.appfe4.type=ajp13
worker.appfe4.port=8009
worker.appfe4.host=appfe4
worker.appfe4.socket_timeout=5
worker.appfe4.socket_keepalive=true
worker.appfe4.prepost_timeout=5
worker.appfe4.connect_timeout=5000
worker.appfe4.retries=3
worker.appfe4.recycle_timeout=900
# Refererence BHP Apache tuning guide before uncomment the following
line. The unit of reply_timeout is millisecond.
#worker.appfe4.reply_timeout=0
On Tue, Feb 24, 2009 at 4:50 PM, Rainer Jung <ra...@kippdata.de> wrote:
> On 25.02.2009 00:00, Mohit Anchlia wrote:
>>
>> Reposting:
>>
>> Apache Server - 2.2
>> Tomcat server 6
>> Jboss - 4.2
>>
>> We have Web Servers talking to Jboss App Servers over mod_jk. When we
>> do our patch or upgrade of software we do it in rolling fashion so
>> that there is "0" customer impact. But it looks like mod_jk load
>> balancer on Web server doesn't detect it as soon as Jboss App Server
>> goes down. Our goal is to have 0 customer impact. So my question is
>> what can we do to overcome this problem. Web Server sees Http Error
>> Code 503.
>>
>> Information from log file:
>>
>> [Mon Feb 23 13:39:42.146 2009] [31682:4143745888] [error]
>> ajp_connection_tcp_get_message::jk_ajp_common.c (966): (appfe4) can't
>> receive the response message from tomcat, network problems or tomcat
>> (10.10.81.89:8009) is down (errno=104)
>> [Mon Feb 23 13:39:42.147 2009] [31682:4143745888] [error]
>> ajp_service::jk_ajp_common.c (2097): (appfe4) Connecting to tomcat
>> failed. Tomcat is probably not started or is listening on the wrong
>> port
>
> This means that mod_jk detected that your backend is down and thus puts it
> into an error state. All following requests will no longer be sent to this
> backend. Once a minute it will send a request there and try, but as long as
> it is down this test will not succeed and thus all requests will be sent to
> other nodes.
>
> The first request that gets sent to the backend you stopped might get an
> error back. If you want to prevent that from happening, use Cping/Cpong:
>
> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>
> so we will detect the broken node before actually sending a request there.
> More details are not possible to give without your JK configuration (Jk
> directive sin httpd configuration files, workers.properties and if used
> uriworkermap.properties).
>
> The line number of the above message tells me you are using mod_jk 1.2.25.
> Although there's nothing wrong in principal with 1.2.25, we always try to
> improve and you might consider switching to 1.2.27.
>
> You should also increase your JkLogLevel to info. As long as only occasional
> info messages are in your log file everything is fine, but once error
> messages show up, the additional info messages contain useful formation.
>
> 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 not working as expected - is there a bug??
Posted by Rainer Jung <ra...@kippdata.de>.
On 25.02.2009 00:00, Mohit Anchlia wrote:
> Reposting:
>
> Apache Server - 2.2
> Tomcat server 6
> Jboss - 4.2
>
> We have Web Servers talking to Jboss App Servers over mod_jk. When we
> do our patch or upgrade of software we do it in rolling fashion so
> that there is "0" customer impact. But it looks like mod_jk load
> balancer on Web server doesn't detect it as soon as Jboss App Server
> goes down. Our goal is to have 0 customer impact. So my question is
> what can we do to overcome this problem. Web Server sees Http Error
> Code 503.
>
> Information from log file:
>
> [Mon Feb 23 13:39:42.146 2009] [31682:4143745888] [error]
> ajp_connection_tcp_get_message::jk_ajp_common.c (966): (appfe4) can't
> receive the response message from tomcat, network problems or tomcat
> (10.10.81.89:8009) is down (errno=104)
> [Mon Feb 23 13:39:42.147 2009] [31682:4143745888] [error]
> ajp_service::jk_ajp_common.c (2097): (appfe4) Connecting to tomcat
> failed. Tomcat is probably not started or is listening on the wrong
> port
This means that mod_jk detected that your backend is down and thus puts
it into an error state. All following requests will no longer be sent to
this backend. Once a minute it will send a request there and try, but as
long as it is down this test will not succeed and thus all requests will
be sent to other nodes.
The first request that gets sent to the backend you stopped might get an
error back. If you want to prevent that from happening, use Cping/Cpong:
http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
so we will detect the broken node before actually sending a request
there. More details are not possible to give without your JK
configuration (Jk directive sin httpd configuration files,
workers.properties and if used uriworkermap.properties).
The line number of the above message tells me you are using mod_jk
1.2.25. Although there's nothing wrong in principal with 1.2.25, we
always try to improve and you might consider switching to 1.2.27.
You should also increase your JkLogLevel to info. As long as only
occasional info messages are in your log file everything is fine, but
once error messages show up, the additional info messages contain useful
formation.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org