Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
This account does not exist - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Could one of the more senior jtc committers review this for me please?
The problem was that jk_lb_refresh was being called for each channel
parsed and adding all the workers to the workersTable each time. The
result was that the first channel was added to the table n+1 times
(where n = total number of workers), the second channel was added n
times and the third channel n-1, etc. Consequently the table was
getting overrun.
I believe this problem may also account for the first channel(s)
getting more load because of the extra copies in the table.
-Kurt
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 08, 2004 6:01 PM
Subject: cvs commit: jakarta-tomcat-connectors/jk/native2/common
jk_worker_lb.c
truk2004/03/08 15:01:07
Modified:jk/native2/common jk_worker_lb.c
Log:
Fix bug 23483
Only add worker to the workerTable if it is not already there.
Add check for maximum workers too.
Revision ChangesPath
1.38 +21 -5
jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c
Index: jk_worker_lb.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- jk_worker_lb.c 27 Feb 2004 08:34:18 - 1.37
+++ jk_worker_lb.c 8 Mar 2004 23:01:06 - 1.38
@@ -448,7 +448,8 @@
char *name = lb-lbWorkerMap-nameAt( env,
lb-lbWorkerMap, i);
jk_worker_t *w= env-getByName( env, name );
int level=0;
-int pos=0;
+int pos;
+int workerCnt;
if( w== NULL ) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
@@ -463,12 +464,27 @@
/* It's like disabled */
if( level = JK_LB_LEVELS ) continue;
-pos=lb-workerCnt[level]++;
+/* check if worker is already in the table */
+workerCnt = lb-workerCnt[level];
+for(pos = 0 ; pos workerCnt ; pos++) {
+if( lb-workerTables[level][pos] == w ) {
+break;
+}
+}
+
+if( pos == workerCnt ) {
+if( pos == JK_LB_MAX_WORKERS ) {
+env-l-jkLog(env, env-l, JK_LOG_ERROR,
+ lb_worker.init(): maximum lb
workers reached %s\n, name);
+continue;
+}
+pos=lb-workerCnt[level]++;
-lb-workerTables[level][pos]=w;
+lb-workerTables[level][pos]=w;
-w-lb_value = w-lb_factor;
-w-in_error_state = JK_FALSE;
+w-lb_value = w-lb_factor;
+w-in_error_state = JK_FALSE;
+}
}
return JK_OK;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
No, but extending one dtd would be better than reinventing everything. I will try to make a cleanup as soon as I have time. (docs need a lot of time). I confirm ;-) BTW, any DTD will be fine but we should take a look at what others jakarta and xml projects are using. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Costin Manolache wrote: Mladen Turk wrote: -Original Message- On Behalf Of Costin Manolache Are we documenting all those settings - and the details on why/how :-) ? Sure, like everyone else ;). Yes, I know :-) I'll try to get over the horrible and nonstandard DTD that we use I agree for not standard DTD but horrible... Well it needs a lot of improvements but that means the xml files need to be reviewed carefully I would suggest to output messages when using weird elements to have time to rewrite the files. and start documenting what I can still remember, and anything new that I add. And I won't write any new jk code until I finish at least reviewing all the bugs ( 80 ? ) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
jean-frederic clere wrote: Costin Manolache wrote: Mladen Turk wrote: -Original Message- On Behalf Of Costin Manolache Are we documenting all those settings - and the details on why/how :-) ? Sure, like everyone else ;). Yes, I know :-) I'll try to get over the horrible and nonstandard DTD that we use I agree for not standard DTD but horrible... Well it needs a lot of improvements but that means the xml files need to be reviewed carefully I would suggest to output messages when using weird elements to have time to rewrite the files. :-) Sorry about 'horrible'. What I meant is - the elements like section and almost everything else have an identical meaning as the standard XHTML or docbook element. It's a mix of elements - to do something that is already done and standard and accepted. What I find horrible is the fragmentation and missuse of XML ( not only here, but all over ). What's wrong with a subset of XHTML or Docbook ? Do we plan to beat W3C and Oasis in setting a standard for document dtd ? ( well, that's just me ranting - this has little to do with our xdocs, as I said I'll try to get over it and add to them ) -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Costin Manolache wrote: jean-frederic clere wrote: Costin Manolache wrote: Mladen Turk wrote: -Original Message- On Behalf Of Costin Manolache Are we documenting all those settings - and the details on why/how :-) ? Sure, like everyone else ;). Yes, I know :-) I'll try to get over the horrible and nonstandard DTD that we use I agree for not standard DTD but horrible... Well it needs a lot of improvements but that means the xml files need to be reviewed carefully I would suggest to output messages when using weird elements to have time to rewrite the files. :-) Sorry about 'horrible'. What I meant is - the elements like section and almost everything else have an identical meaning as the standard XHTML or docbook element. It's a mix of elements - to do something that is already done and standard and accepted. What I find horrible is the fragmentation and missuse of XML ( not only here, but all over ). What's wrong with a subset of XHTML or Docbook ? The first idea was to save us from writing XML tags and concentrate in the text. We have ended defining a dtd that fits our needs with typing the minimum... Do we plan to beat W3C and Oasis in setting a standard for document dtd ? No, but extending one dtd would be better than reinventing everything. I will try to make a cleanup as soon as I have time. (docs need a lot of time). ( well, that's just me ranting - this has little to do with our xdocs, as I said I'll try to get over it and add to them ) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
jean-frederic clere wrote: :-) Sorry about 'horrible'. What I meant is - the elements like section and almost everything else have an identical meaning as the standard XHTML or docbook element. It's a mix of elements - to do something that is already done and standard and accepted. What I find horrible is the fragmentation and missuse of XML ( not only here, but all over ). What's wrong with a subset of XHTML or Docbook ? The first idea was to save us from writing XML tags and concentrate in the text. We have ended defining a dtd that fits our needs with typing the minimum... I'm not sure I understand. How is this 'saving us' from writing XML tags? We still have to write XML tags, and what's worse - to learn a set of tags that we'll never use outside jk. As oposed to write the same thing using the tags we already know - subset of XHTML - or learn a set of tags that we'll likely use - a subset of docbook. And both XHTML and Docbook have editors and tools that would actually 'save us from writing XML' and concentrate on text. And plenty of stylesheets to generate pdf or whatever else. Do we plan to beat W3C and Oasis in setting a standard for document dtd ? No, but extending one dtd would be better than reinventing everything. I will try to make a cleanup as soon as I have time. (docs need a lot of time). ??? We do reinvent everything aparently - yet another non-standard document DTD. W3C and Oasis define some reasonable and widely used DTDs for that. If someone feels docbook is too complex - we can restrict ourselfs to a subset ( like linuxdoc did for a while ) , but we'll still benefit from some of the existing tools and what we already know. As I said, that's just me ranting - if the majority is happy with our private DTD for docs - I'll have to use it ( but that doesn't mean I have to like it ). -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
-Original Message- From: [EMAIL PROTECTED] Modified:jk/native2/common jk_worker_lb.c Log: Introduced 3 new configuration parameters to the lb. 1. attempts -- replaces harcoded MAX_ATTEMPTS 2. recovery -- replaces hardcoded WAIT_BEFORE_RECOVER 3. timeout -- this one is new. The timeout if set will force the lb to cycle through workers if all are in the error_state for the specified amount of seconds. This is usefull for situations when the TC is overloaded and refuses new connections. The lb will wait and after timeout will report 500 to the client. Some more clarification: The reason for introducing timeout inside lb is from my point of view and the applications I'm using jk2 for, fact that even using most powerful system, there will be situations that returns 500 to the client simply because the TC is to busy and refuses new connections. One way to solve that is to force the TC to allow more connections eating system resources, and the other is using lb timeout. One drawback of using timeout is the fact that the client will get delayed response even for the non-existent configured TC instance. I've made such behavior at first inside the socket connector, but Nacho (he was right) made a strong objection to that. So instead trying to connect to the instance from connector point of view, all that is put inside the load balancer. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
De: Mladen Turk [mailto:[EMAIL PROTECTED]] Enviado el: 2 de octubre de 2002 17:50 I there any way to disable completely that timeout? Perhaps setting it to -1 or something like that? This timeout disabled should be the default config.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
It is disabled by default and never checked (if you don't set the timeout=x inside the [lb]). I there any way to disable completely that timeout? Perhaps setting it to -1 or something like that? This timeout disabled should be the default config.. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Are we documenting all those settings - and the details on why/how :-) ? Mladen Turk wrote: It is disabled by default and never checked (if you don't set the timeout=x inside the [lb]). I there any way to disable completely that timeout? Perhaps setting it to -1 or something like that? This timeout disabled should be the default config.. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
-Original Message- On Behalf Of Costin Manolache Are we documenting all those settings - and the details on why/how :-) ? Sure, like everyone else ;). MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Mladen Turk wrote: -Original Message- On Behalf Of Costin Manolache Are we documenting all those settings - and the details on why/how :-) ? Sure, like everyone else ;). Yes, I know :-) I'll try to get over the horrible and nonstandard DTD that we use and start documenting what I can still remember, and anything new that I add. And I won't write any new jk code until I finish at least reviewing all the bugs ( 80 ? ) -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
-Original Message- Sure, like everyone else ;). Yes, I know :-) I'll try to get over the horrible and nonstandard DTD that we use and start documenting what I can still remember, and anything new that I add. And I won't write any new jk code until I finish at least reviewing all the bugs ( 80 ? ) Roger to that. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
[EMAIL PROTECTED] wrote: On Tue, 14 May 2002, Bernd Koecke wrote: Hi Costin, the new patch seems to work, but I'll test it more exactly tomorrow. Then I'll create the patches and the functional description. In short, the patched lb_worker uses an additinal flag on the other workers (e.g worker.ajp13.local_worker=1) to determine if it should be moved to the beginning of the balanced_workers. So we don't need to deal with two lists in lb_worker and the lb_value '0' has no special meaning. The flag for sending requests only to local workers is 'local_worker_only' on the lb_worker. More when the patch is tested and ready. Ok. I already commited part of the changes for jk2 - but my version is called 'hwBalanceErr', on worker_lb. If 0 normal selection of non-local workers takes place if all locals are in error state. If non 0, we'll return the value as the error code - for a front-end balancer to detect and stop forwarding requests for this instance. I think that's the behavior you need - and it also allows customization for the returned error code. That sounds great, many thanks! The patch for jk1 is on the way and I added some explanation how it works and about the two config flags. Bernd Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
[EMAIL PROTECTED] wrote: On Mon, 13 May 2002, Bernd Koecke wrote: Sorry, I must say it again, for my environment it is an error, if a _switched off_ tomcat got a request without a sessionid or with a session from another node. Its not necessary that this tomact-apache tandem is In the current code ( in jk2 ), if a worker is in 'disabled' state it'll only get requests with sessionid, as you need. If it is not disabled, but has a higher level ( == distance ), it'll still not get any new requests unless all closer workers are in error state. update and start them up again. If there are no local/main worker I need an error response and no routing to a switched off tomcat. Its possible that this happens once per day. Setting the non-local workers in disabled state should do that. I know this might be a special environment. I spent some time in jk1 to build a working patch. Than I started looking in jk2. I'm not a good C Your patch looks ok. Would it be possible to remove the use of '0' as a special value, and keep only the main_worker_mode flag for that ? Also, what's the meaning of 'reject' flag ? The '0' as lb_value is needed to determine which are the main/local-workers. If we don't have this special value we need an additional config-flag with a list of the local/main-workers like in Mathias patch. Should I add an additional config-flag (I will take it from Mathias patch) or do we stay with the special '0' value? The reject value of the 'main_worker_mode' flag is for the special behavior not to balance even if no main-worker is up. Without this flag you would send a request to a non main-worker if all main-workers are in error state. When the main-workers are only a preference it might be ok to send a request to a non main-worker and lose only the session but don't send an error response. I think this was what Mathias said. But I need an error response if the main-worker is down. The 'main_worker_mode' is not the same like the 'in_main_worker_mode' var in lb_worker struct. If 'main_worker_mode' flag is set to 'reject' in the workers.properties the reject var of lb_worker struct is set to JK_TRUE. The 'in_main_worker_mode' var of lb_worker struct is set to JK_TRUE if there is in minimum one worker with '0' as lb_value. Also it would be nice to get some documentation for the new settings. Thats no problem, I could write a patch for the HTML-page. Regarding jk2 - I just want to know if the current solution is ok or what are still problems. For now the priority is getting the patch in jk1 so it can be released in 4.0.4 final ( so today or early tommorow I would like to close this issue ). This sounds pretty good, many thanks! Bernd Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
The '0' as lb_value is needed to determine which are the main/local-workers. If we don't have this special value we need an additional config-flag with a list of the local/main-workers like in Mathias patch. Should I add an additional config-flag (I will take it from Mathias patch) or do we stay with the special '0' value? It will be very usefull to make a short documentation on latest lb work mode and configuration. Like a descriptive mail to this list, I'll commit mod_jk document accordingly... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
GOMEZ Henri wrote: The '0' as lb_value is needed to determine which are the main/local-workers. If we don't have this special value we need an additional config-flag with a list of the local/main-workers like in Mathias patch. Should I add an additional config-flag (I will take it from Mathias patch) or do we stay with the special '0' value? It will be very usefull to make a short documentation on latest lb work mode and configuration. Like a descriptive mail to this list, I'll commit mod_jk document accordingly... A short description of my latest patch is in my mail from 6.May 18:23 CEST. If we add a new conf-flag I will test it localy and send a detailed description with the patch. If we don't add a flag I'll send a more detailed description about the latest patch. Bernd -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
On Tue, 14 May 2002, Bernd Koecke wrote: The '0' as lb_value is needed to determine which are the main/local-workers. If we don't have this special value we need an additional config-flag with a list of the local/main-workers like in Mathias patch. Should I add an additional config-flag (I will take it from Mathias patch) or do we stay with the special '0' value? I think it would be a good idea, it'll make things cleaner. 'local_worker' would be allways selected, and if 'main_worker_mode' ( or maybe 'hw_lb_mode' ) no fallback will happen. The 'main_worker_mode' is not the same like the 'in_main_worker_mode' var in lb_worker struct. If 'main_worker_mode' flag is set to 'reject' in the workers.properties the reject var of lb_worker struct is set to JK_TRUE. The 'in_main_worker_mode' var of lb_worker struct is set to JK_TRUE if there is in minimum one worker with '0' as lb_value. That's a bit confusing. Maybe some better variable names are needed. 2 flags should be enough - 'local_worker' and 'local_worker_only' ( or something that makes it clear that if the flag is set, no fallback will occur but an error is returned for the hw balancer ). I'll implement the same thing in jk2, but I wait your patch for jk1. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
[EMAIL PROTECTED] wrote: On Tue, 14 May 2002, Bernd Koecke wrote: The '0' as lb_value is needed to determine which are the main/local-workers. If we don't have this special value we need an additional config-flag with a list of the local/main-workers like in Mathias patch. Should I add an additional config-flag (I will take it from Mathias patch) or do we stay with the special '0' value? I think it would be a good idea, it'll make things cleaner. 'local_worker' would be allways selected, and if 'main_worker_mode' ( or maybe 'hw_lb_mode' ) no fallback will happen. The 'main_worker_mode' is not the same like the 'in_main_worker_mode' var in lb_worker struct. If 'main_worker_mode' flag is set to 'reject' in the workers.properties the reject var of lb_worker struct is set to JK_TRUE. The 'in_main_worker_mode' var of lb_worker struct is set to JK_TRUE if there is in minimum one worker with '0' as lb_value. That's a bit confusing. Maybe some better variable names are needed. 2 flags should be enough - 'local_worker' and 'local_worker_only' ( or something that makes it clear that if the flag is set, no fallback will occur but an error is returned for the hw balancer ). Ok, how should we handle the local_worker list? The current code depends on one worker list. And for requests with a session its easier to look into one list. Is it ok to have the balanced_workers and one ore more of these workers could be in the local_worker list? Then we could leave must of the code in validate function untouched and after getting all the workers we go through the local_worker list, if any, and move the worker from this list at the beginning of the balanced_workers and mark them as local. Would this be ok? Oterwise we have to handle two lists and it would be possible to have only local workers and no balanced_workers. Then the lb_module makes no sense, but it is configurable and we have to deal with this. Another solution is to have two lists in config but only one in lb_worker. But then we have to rewrite most of the code in validate and handle memory etc. You know I'm not so experienced in C, so I would prefere the first suggestion :). Bernd I'll implement the same thing in jk2, but I wait your patch for jk1. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
[EMAIL PROTECTED] wrote: [...] I'll implement the same thing in jk2, but I wait your patch for jk1. Hi Costin, the new patch seems to work, but I'll test it more exactly tomorrow. Then I'll create the patches and the functional description. In short, the patched lb_worker uses an additinal flag on the other workers (e.g worker.ajp13.local_worker=1) to determine if it should be moved to the beginning of the balanced_workers. So we don't need to deal with two lists in lb_worker and the lb_value '0' has no special meaning. The flag for sending requests only to local workers is 'local_worker_only' on the lb_worker. More when the patch is tested and ready. Bernd Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
On Tue, 14 May 2002, Bernd Koecke wrote: Hi Costin, the new patch seems to work, but I'll test it more exactly tomorrow. Then I'll create the patches and the functional description. In short, the patched lb_worker uses an additinal flag on the other workers (e.g worker.ajp13.local_worker=1) to determine if it should be moved to the beginning of the balanced_workers. So we don't need to deal with two lists in lb_worker and the lb_value '0' has no special meaning. The flag for sending requests only to local workers is 'local_worker_only' on the lb_worker. More when the patch is tested and ready. Ok. I already commited part of the changes for jk2 - but my version is called 'hwBalanceErr', on worker_lb. If 0 normal selection of non-local workers takes place if all locals are in error state. If non 0, we'll return the value as the error code - for a front-end balancer to detect and stop forwarding requests for this instance. I think that's the behavior you need - and it also allows customization for the returned error code. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Mathias Herberts wrote: [EMAIL PROTECTED] wrote: costin 02/05/09 14:06:48 Modified:jk/native2/common jk_worker_lb.c Log: That's the big one. Please review ! It changes the handling of lb_value to int. I also cleaned up the logic so it's easier ( I hope ) to understand what's happening. Levels replace the 'local worker', I thing I got the logic straight for those. I started to add a 'introspection' data, to validate and better report the config. We use one table per level. At the moment the maximum number of workers is hardcoded ( to 255 ), we could make it dynamic but that would make things pretty complex when we add workers dynamically ( it won't work without a CS or atomic operations ) Hi Costin, I read your code throughly and found no problem in get_most_suitable_worker, I think your approach to prioritizing workers is the best. What bernd and I had done was mainly driven by the need to have a frontal load balancer detect the failure of the local worker(s). Since my last patch and having read yours I think I found a better way to make the load balancer detect failures. Configure all Apache instances so they see all Tomcat instances, assign a higher priority to local workers on each Apache, therefore local workers will be chosen first. On each Apache, the load balancing worker is called lb. Another load balancing worker, balancing only the local workers, is called hwlb. The hardware load balancer checks the health of the Apache servers using a URI which is served by hwlb instead of lb, therefore if there are no more local workers left alive, the requests the hardware load balancer dispatches to the associated Apache before it can detect the local workers failure will be rerouted to the other non local workers and the client will only loose its session information, she will not get any errors. When the hardware load balancer ends up detecting the local workers failure (because the hwlb worker rejected the request due to the lack of available worker), it will declare the Apache inactive and will only use the other ones. This setup solves my use cases at least, I don't know for Bernd's. Sorry, I must say it again, for my environment it is an error, if a _switched off_ tomcat got a request without a sessionid or with a session from another node. Its not necessary that this tomact-apache tandem is shut down. We switch off a port on this node and than the balancer wouldn't send a request to it. And than no mod_jk is allowed to send a request to it without a session for this node. It is normal that some nodes are _switched off_. We need this for a a graceful update. We switch off some nodes, wait till there are no active sessions (all timed out) and then we shutdown apache + tomcat, make an update and start them up again. If there are no local/main worker I need an error response and no routing to a switched off tomcat. Its possible that this happens once per day. I know this might be a special environment. I spent some time in jk1 to build a working patch. Than I started looking in jk2. I'm not a good C developer, so I needed some time for looking into jk2. Now I think I understand the internal structure. I don't want to send untested patches or patches which build more problems than it solves. The last patch I sent for jk1 solved my problem, I tested it here on a testcluster and I hope it broke no prior functionality. But it will take some time till I could send a patch for jk2. My boss give me some deadlines for other projects, one is next Wednesday. I would be happy if jk2 make it possible to use local/main-worker with sticky sessions (need only one per node/mod_jk). And if all local/main-worker are down the request gets an error-response. I will do my best to install a jk2 on my test cluster and try to play around with it. May be I misunderstood Mathias suggestion for jk2, than delete the whole mail :). I hope I could send a patch for jk2 or look into the new code shortly. Again, I think its a very good idea to use ints for lb_value, set a maximum and correct the value if one reaches this upper bound. And its a good idea to make the local/main-worker a more general thing. For a cluster environment it is a nice feature :). Thanks Bernd There remains a related problem in jk_requtil in jk2_requtil_getCookieByName, as I mentioned several months ago on the list, the cookie extraction does not work for cookies whose format conforms to RFC 2169, that is the cookie value is enclosed in double quotes. Such cookie format is used by lynx for example. I had submitted a patch into the bug database but cannot find it anymore, I'll have to look up my archives. Good job on the lb worker Costin, Mathias. -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
On Mon, 13 May 2002, Bernd Koecke wrote: Sorry, I must say it again, for my environment it is an error, if a _switched off_ tomcat got a request without a sessionid or with a session from another node. Its not necessary that this tomact-apache tandem is In the current code ( in jk2 ), if a worker is in 'disabled' state it'll only get requests with sessionid, as you need. If it is not disabled, but has a higher level ( == distance ), it'll still not get any new requests unless all closer workers are in error state. update and start them up again. If there are no local/main worker I need an error response and no routing to a switched off tomcat. Its possible that this happens once per day. Setting the non-local workers in disabled state should do that. I know this might be a special environment. I spent some time in jk1 to build a working patch. Than I started looking in jk2. I'm not a good C Your patch looks ok. Would it be possible to remove the use of '0' as a special value, and keep only the main_worker_mode flag for that ? Also, what's the meaning of 'reject' flag ? Also it would be nice to get some documentation for the new settings. Regarding jk2 - I just want to know if the current solution is ok or what are still problems. For now the priority is getting the patch in jk1 so it can be released in 4.0.4 final ( so today or early tommorow I would like to close this issue ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
[EMAIL PROTECTED] wrote: costin 02/05/09 14:06:48 Modified:jk/native2/common jk_worker_lb.c Log: That's the big one. Please review ! It changes the handling of lb_value to int. I also cleaned up the logic so it's easier ( I hope ) to understand what's happening. Levels replace the 'local worker', I thing I got the logic straight for those. I started to add a 'introspection' data, to validate and better report the config. We use one table per level. At the moment the maximum number of workers is hardcoded ( to 255 ), we could make it dynamic but that would make things pretty complex when we add workers dynamically ( it won't work without a CS or atomic operations ) Hi Costin, I read your code throughly and found no problem in get_most_suitable_worker, I think your approach to prioritizing workers is the best. What bernd and I had done was mainly driven by the need to have a frontal load balancer detect the failure of the local worker(s). Since my last patch and having read yours I think I found a better way to make the load balancer detect failures. Configure all Apache instances so they see all Tomcat instances, assign a higher priority to local workers on each Apache, therefore local workers will be chosen first. On each Apache, the load balancing worker is called lb. Another load balancing worker, balancing only the local workers, is called hwlb. The hardware load balancer checks the health of the Apache servers using a URI which is served by hwlb instead of lb, therefore if there are no more local workers left alive, the requests the hardware load balancer dispatches to the associated Apache before it can detect the local workers failure will be rerouted to the other non local workers and the client will only loose its session information, she will not get any errors. When the hardware load balancer ends up detecting the local workers failure (because the hwlb worker rejected the request due to the lack of available worker), it will declare the Apache inactive and will only use the other ones. This setup solves my use cases at least, I don't know for Bernd's. There remains a related problem in jk_requtil in jk2_requtil_getCookieByName, as I mentioned several months ago on the list, the cookie extraction does not work for cookies whose format conforms to RFC 2169, that is the cookie value is enclosed in double quotes. Such cookie format is used by lynx for example. I had submitted a patch into the bug database but cannot find it anymore, I'll have to look up my archives. Good job on the lb worker Costin, Mathias. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Hi Mathias, Thanks for the review. Few comments: Configure all Apache instances so they see all Tomcat instances, assign a higher priority to local workers on each Apache, therefore local What you set is the 'level' ( or proximity, distance, etc ) - lower numbers mean closer ( and higher priority, local worker ). I still need to add and verify the setters and check the various cases. workers, is called hwlb. The hardware load balancer checks the health of the Apache servers using a URI which is served by hwlb instead of lb, You may have noticed the 'jk_status' worker - it displays runtime informations ( still in progress - we need to agregate the statistics from all workers using shm, but the status of the workers should be fine ). It can be easily extended ( or a similar handler added ) so it can generate info that can be 'consumed' by a front load balancer or other tools. Like number of active workers and average response times. I am also investigating how we can use the number of active connections on each worker and the response times in the main lb, any idea would be wellcome :-) This setup solves my use cases at least, I don't know for Bernd's. Ok, but let me know if you find jk2 acceptable for your case and what is the minimal change to jk1 that we can do. I still have to merge your patches, I was waiting for more comments. I don't think we can/should backport the new code, it's far too much. There remains a related problem in jk_requtil in jk2_requtil_getCookieByName, as I mentioned several months ago on the list, the cookie extraction does not work for cookies whose format conforms to RFC 2169, that is the cookie value is enclosed in double quotes. Such cookie format is used by lynx for example. I had submitted a patch into the bug database but cannot find it anymore, I'll have to look up my archives. Please do, and send it to the list ( with PATCH ). I would apreciate 2 patches, one for jk1 and one for jk2 ( if the problem is in both ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
