tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: mod_jk not working as expected - is there a bug??
Date Tue, 03 Mar 2009 01:01:03 GMT
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<rainer.jung@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<rainer.jung@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<rainer.jung@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<rainer.jung@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


Mime
View raw message