Hi Konstantin,
On 04/02/2014 12:01 PM, Konstantin Kolinko wrote:
2014-04-02 5:21 GMT+04:00 Frederik Nosi <frederik.n...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Frederik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
