tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: mod_jk - Failover behaviour and load + patch
Date Wed, 02 Apr 2014 10:01:47 GMT
2014-04-02 5:21 GMT+04:00 Frederik Nosi <>:
> On 04/02/2014 12:21 AM, Christopher Schultz wrote:
>> On 3/26/14, 9:32 PM, Frederik Nosi wrote:
>>> My scenario is Apache httpd + mod_jk + N Tomcat's in. The default
>>> behaviour of load balanced workers in mod_jk in my testing is that
>>> when a client requests a page (GET / POST / Whatever), the LB
>>> worker tries the request to every ajp worker. This in contrast with
>>> what i read here:
>>> <>
>>> Expecially this part:
>>> When having multiple nodes in a cluster you can improve your
>>> application availability by implementing failover. The failover
>>> means that if the particular elected node can not fulfill the
>>> request the another node will be selected automatically. In case of
>>> three nodes you are actually doubling your application
>>> availability. The application response time will be slower during
>>> failover, but none of your users will be rejected. Inside the
>>> mod_jk configuration there is a special configuration parameter
>>> called worker.retries that has default value of 3, but that needs
>>> to be adjusted to the actual number of nodes in the cluster.
>>> ... worker.list=lbworker worker.lbworker.type=lb # Adjust to the
>>> number of workers worker.retries=4
>>> worker.lbworker.balance_workers=node1,node2,node3,node4 If you add
>>> more then three workers to the load balancer adjust the retries
>>> parameter to reflect that number. It will ensure that even in the
>>> worse case scenario the request gets served if there is a single
>>> operable node.
>>>  From that it seems that the "retries" parameter in a load balancer
>>> worker context should mean the number of real (AJP) workers to
>>> try. (what i need indeed) but in my testing, that LB worker
>>> parameter is the number of times that all the AJP workers that are
>>> part of the LB worker get a round retry. In eg, having a LB worker
>>> with 4 AJP workers, setting LB Worker's retries = 2, the behaviour
>>> i see is that the AJP workers get called this way:
>>> AJP1 -> timeout [...] AJP4 -> timeout
>>> ===> repeat again (retries == 2)
>>> AJP1 -> timeout [...] AJP4 -> timeout
>>> --> LB sends an error to the client.
>>> Now from the online documentation the meaning of that parameter in
>>> a load balancer worker context is'nt that clear, but from the link
>>> i provided seems it was exactly what i needed, not the number of
>>> retries to all AJP workers, but the number of single AJP workers to
>>> try..
>>> If that is not correct i can fill a bug report. If instead it's by
>>> design, the attached patch adds a new parameter, "lb_retries", that
>>> does what i need. Of course it's a bit rough, but works.
>>> Any comments? Am I getting stuff wrong?
>> I'm bumping this because I can see Rainer has fixed a bunch of things
>> in mod_jk over the last few days. Perhaps he's getting ready to do a
>> release or something.
> Thanks Christopher, BTW on this issue I'm not even sure it's a documentation
> bug, a bug in mod_jk or an unfullfilled expectation of mine :-)
> Thing is, i had to use this cure.
> I'm sure my patch is a bit faulty, the HTTP status codes returned are > 500,
> but i'm not sure they are in line with the protocol (503 / 504). but for now
> it works for me though.

1. If you really want to submit a patch,  please attach it to an issue
in Bugzilla, so that it is not forgotten.

2. You were lucky that you attachment has reached the list.  Usually
attachments are just removed by mailing list server.

3. I cannot comment on the essence,  just two formal nits
1) The following line has a tab character instead of whitespaces:
+        jk_log(l, JK_LOG_DEBUG, "attempt %d, max attempts %d",

2) An unneeded comment
+/* fredi - default */

3) Documentation =?

> Noticed there were changes in mod_jk's git repo, i'm following it.

It is good that it works for you.
The official repository is subversion one.

(Patches against the git repository are OK.  Maybe you want to submit
those ".gitignore" files, as a separate issue?)

Best regards,
Konstantin Kolinko

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message