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. 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
