tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frederik Nosi <frederik.n...@postecom.it>
Subject Re: mod_jk - Failover behaviour and load + patch
Date Wed, 02 Apr 2014 01:21:53 GMT
Hi Christopher,

On 04/02/2014 12:21 AM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Frederik,
>
> 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:
>>
>>
>> http://people.apache.org/~mturk/docs/article/ftwai.html
>> <http://people.apache.org/%7Emturk/docs/article/ftwai.html>
>>
>> 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.

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

Thanks for your attention and have fun at ApacheCon!
- Fredi

>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJTOzvQAAoJEBzwKT+lPKRY6uEQAISOkIa3VwSlhVEu/JPuhqDD
> SHN7/hui6l/0oj2chPRr1YWs0XO8yuP8afgzlfuJhWQ5fNeVshDliYijYusKZPSx
> 666iVZ4NqVF8zTYo7Y6LE7gJJS8LrZUnD/nEF3ngCWGp5V6KzbQkB2haQBeFFRX2
> bK2xcPFAC/hhT4QmkSkyCb8KaqyGtgIZDXToiQlA1oWRkleRip8yU+JwZEQXUz8v
> MNhRtG5hUiX5z6wJh7OVTRu421mwmfZav4SUNxvjN71UnvoiRST4H3qrQGeD6fHh
> 2bKq4ot+olZ7T0Wo4fd6NqRzn/7fwRfp9U6OIrwe5umjaWzYd99o/iTm31hcFJFz
> f6d1A0A5uqZaDT2+o8y01qSbdIWDYZFKRv7KZuX1/+6WXp6h7VHXhY9mA/R8RYf9
> NpSi0bk5FprrTNJoJx9+q/LBGlFrwFZqJpYfL93FMUlkOP47z2U1Z6ihf+HC4vb9
> zIS/NRBMgYWcKezbcc7E40XHYChE3SedO809AVAyaz7VASAQsfMDVrih0eu7f+w0
> R5FY/32Ks/o0B8Udi3numTAovEE72YjIuuvMZQp9CTGBwNMFQUUsiGAdILSBSULl
> XNgAJXDOEOyVPDMONaHXQPk4xgDH/iZAcNdgqhnV+lcmgnhwSKAV8hz9/wF/u/H8
> qs1OVu0vib9AXJ6ZFFEh
> =GEhg
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message