You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2014/04/02 00:21:04 UTC
Re: mod_jk - Failover behaviour and load + patch
-----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.
- -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
Re: mod_jk - Failover behaviour and load + patch
Posted by Frederik Nosi <fr...@postecom.it>.
Hi Konstantin,
On 04/02/2014 12:01 PM, Konstantin Kolinko wrote:
> 2014-04-02 5:21 GMT+04:00 Frederik Nosi <fr...@postecom.it>:
>> 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:
>>>>
>>>>
>>>> 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.
>>
> 1. If you really want to submit a patch, please attach it to an issue
> in Bugzilla, so that it is not forgotten.
Okay, i will,
>
> http://tomcat.apache.org/bugreport.html
>
> 2. You were lucky that you attachment has reached the list. Usually
> attachments are just removed by mailing list server.
Ok, sorry for that, i put that as attachment for avoiding word wrapping
problems with my
mail client.
>
> 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",
Ok, willl fix, thanks for pointing this.
>
> 2) An unneeded comment
> +/* fredi - default */
Yep, leftover from my testing
>
> 3) Documentation =?
> (xdocs/reference/workers.xml)
Ok, will do,
>
>> 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.
Yes, noticed that, but as i'm not always inline i tend to use git. But
svn is fine too
>
> (Patches against the git repository are OK. Maybe you want to submit
> those ".gitignore" files, as a separate issue?)
Okay, will separate that part in case it turns useful.
Anyway, i know the patch i sent was rough, but i prefered to send it
anyway to have
something concrete to explain what i wanted to do.
>
> Best regards,
> Konstantin Kolinko
Thanks Konstantin for your attention!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Frederik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk - Failover behaviour and load + patch
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-04-02 5:21 GMT+04:00 Frederik Nosi <fr...@postecom.it>:
> 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:
>>>
>>>
>>> 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.
>
1. If you really want to submit a patch, please attach it to an issue
in Bugzilla, so that it is not forgotten.
http://tomcat.apache.org/bugreport.html
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 =?
(xdocs/reference/workers.xml)
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk - Failover behaviour and load + patch
Posted by Frederik Nosi <fr...@postecom.it>.
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