tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohit Anchlia <mohitanch...@gmail.com>
Subject Re: mod_jk not working as expected - is there a bug??
Date Tue, 03 Mar 2009 00:45:54 GMT
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 <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.
>>>>>>>
>>>>>>> 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


Mime
View raw message