Loadbalancer problems in mod_jk 4.0.3 [was Native Connector problems]
)]: Into jk_endpoint_t::service [Tue Feb 12 15:28:32 2002] [jk_ajp13_worker.c (865)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:28:32 2002] [jk_ajp13_worker.c (775)]: Into jk_endpoint_t::service [Tue Feb 12 15:28:32 2002] [jk_ajp13.c (403)]: Into ajp13_marshal_into_msgb [Tue Feb 12 15:28:32 2002] [jk_ajp13.c (537)]: ajp13_marshal_into_msgb - Done [Tue Feb 12 15:28:32 2002] [jk_connect.c (108)]: Into jk_open_socket [Tue Feb 12 15:28:32 2002] [jk_connect.c (115)]: jk_open_socket, try to connect socket = 38 [Tue Feb 12 15:28:32 2002] [jk_connect.c (124)]: jk_open_socket, after connect ret = 0 [Tue Feb 12 15:28:32 2002] [jk_connect.c (132)]: jk_open_socket, set TCP_NODELAY to on [Tue Feb 12 15:28:32 2002] [jk_connect.c (140)]: jk_open_socket, return, sd = 38 [Tue Feb 12 15:28:32 2002] [jk_ajp13_worker.c (189)]: In jk_endpoint_t::connect_to_tomcat, connected sd = 38 [Tue Feb 12 15:28:32 2002] [jk_ajp13_worker.c (206)]: sending to ajp13 #436 [Tue Feb 12 15:28:32 2002] [jk_ajp13_worker.c (645)]: send_request 2: request body to send 0 - request body to resend 0 [Tue Feb 12 15:28:34 2002] [jk_ajp13_worker.c (258)]: received from ajp13 #82 4.0.2 version of mod_jk: [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI '/einsurance/doEntry.do' [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (489)]: jk_uri_worker_map_t::map_uri_to_worker, Found a context match loadbalancer - /einsurance/ [Tue Feb 12 15:27:02 2002] [jk_worker.c (132)]: Into wc_get_worker_for_name loadbalancer [Tue Feb 12 15:27:02 2002] [jk_worker.c (136)]: wc_get_worker_for_name, done found a worker [Tue Feb 12 15:27:02 2002] [jk_lb_worker.c (487)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:27:02 2002] [jk_lb_worker.c (306)]: Into jk_endpoint_t::service [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (1345)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (1075)]: Into jk_endpoint_t::service [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (280)]: Into ajp_marshal_into_msgb [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_t::map_uri_to_worker [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI '/einsurance/doEntry.do' [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (489)]: jk_uri_worker_map_t::map_uri_to_worker, Found a context match loadbalancer - /einsurance/ [Tue Feb 12 15:27:02 2002] [jk_worker.c (132)]: Into wc_get_worker_for_name loadbalancer [Tue Feb 12 15:27:02 2002] [jk_worker.c (136)]: wc_get_worker_for_name, done found a worker [Tue Feb 12 15:27:02 2002] [jk_lb_worker.c (487)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:27:02 2002] [jk_lb_worker.c (306)]: Into jk_endpoint_t::service [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (1345)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (1075)]: Into jk_endpoint_t::service [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (280)]: Into ajp_marshal_into_msgb [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_t::map_uri_to_worker [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI '/einsurance/doEntry.do' [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (489)]: jk_uri_worker_map_t::map_uri_to_worker, Found a context match loadbalancer - /einsurance/ [Tue Feb 12 15:27:02 2002] [jk_worker.c (132)]: Into wc_get_worker_for_name loadbalancer [Tue Feb 12 15:27:02 2002] [jk_worker.c (136)]: wc_get_worker_for_name, done found a worker [Tue Feb 12 15:27:02 2002] [jk_lb_worker.c (487)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:27:02 2002] [jk_lb_worker.c (306)]: Into jk_endpoint_t::service [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (1345)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (1075)]: Into jk_endpoint_t::service [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (280)]: Into ajp_marshal_into_msgb [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_t::map_uri_to_worker Thanks a lot for looking into this, Best Regards, Hans -Ursprungliche Nachricht- Von: Hans Schmid [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 13. Februar 2002 08:23 An: Tomcat Developers List Betreff: AW: Native Connector problems Hi, I just ran into a problem with the loadbalancing stuff. I built mod_jk.so from the 4.0.2 connector package and replaced my mod_jk.so (TC3.3 Version) with this one in apache/libexec (1.3.19). By just changing a link back and forth between the two versions, I tested our TC3.3 based application against the two versions of mod_jk. If this is not enough and I am missing something, please let me know. Otherwise exactly the same setup All works perfectly with the new mod_jk when I use normal ajp13 workers (one webapp), but fails when I use a loadbalancing worker pointing to another webapp on a different Tomcat instance. I do not have the mod_jk.log here at home. Will send it in a couple of hours when I am in the office
Re: Native Connector problems
The problem is that the default cache size is one and in the ajp_init function in jk_ajp_common.c we return from inside of an if when we initialize the cache so the secrect member of the structure never gets initialized. This caused some GPFs in certain cases on some of my builds. I've checked in the fix. All I did was move the line that initializes secret up above the if statement. Remy, would it be possible to relabel jk_ajp_common.c rev. 1.24 as the rev for tomcat_402? I've built and tested this fix on NetWare and the resolved my GPFs and bad behavior talking to older installations of Tomcat (i.e. 3.3). I was able to use the same module to talk to Tomcat 4.0.2 and Tomcat 3.3 from the same instance of the web server. I love it when a plan comes together :-) I've retagged the file. Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Native Connector problems
Remy Maucherat wrote: The problem is that the default cache size is one and in the ajp_init function in jk_ajp_common.c we return from inside of an if when we initialize the cache so the secrect member of the structure never gets initialized. This caused some GPFs in certain cases on some of my builds. I've checked in the fix. All I did was move the line that initializes secret up above the if statement. Remy, would it be possible to relabel jk_ajp_common.c rev. 1.24 as the rev for tomcat_402? I've built and tested this fix on NetWare and the resolved my GPFs and bad behavior talking to older installations of Tomcat (i.e. 3.3). I was able to use the same module to talk to Tomcat 4.0.2 and Tomcat 3.3 from the same instance of the web server. I love it when a plan comes together :-) I've retagged the file. Nice... But the tarballs should be redone, should n't they? Then how to know that a 4.0.2 tarballs (connectors) is a good one? I would have retagged jakarta-tomcat-connectors as tomcat_402_01 and will rebuild the tarballs as jakarta-tomcat-connectors-4.0.2-01-src.* Any comments? Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re[2]: Native Connector problems
Where are the binary builds of the native connectors for 4.0.2? When can we expect them? Can you quantify the term shortly? Jonathan Reply Separator Subject:Re: Native Connector problems Author: Tomcat Developers List [EMAIL PROTECTED] Date: 2/13/2002 1:17 AM The problem is that the default cache size is one and in the ajp_init function in jk_ajp_common.c we return from inside of an if when we initialize the cache so the secrect member of the structure never gets initialized. This caused some GPFs in certain cases on some of my builds. I've checked in the fix. All I did was move the line that initializes secret up above the if statement. Remy, would it be possible to relabel jk_ajp_common.c rev. 1.24 as the rev for tomcat_402? I've built and tested this fix on NetWare and the resolved my GPFs and bad behavior talking to older installations of Tomcat (i.e. 3.3). I was able to use the same module to talk to Tomcat 4.0.2 and Tomcat 3.3 from the same instance of the web server. I love it when a plan comes together :-) I've retagged the file. Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This email and any files transmitted with it are for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. This email message has been swept by a virus software product for the presence of computer viruses. * -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Native Connector problems
On Wed, 2002-02-13 at 15:40, [EMAIL PROTECTED] wrote: If you ever see any commit (from me) that late in a release cycle - make sure you -1 it, regardless of how usefull it may look. Peer review seems to work well, but it needs more time. After half a billion commits you introduced a bug. You are being too hard on yourself... :-) Best of luck with PMC election! Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Native Connector problems
Mea culpa... One of the last changes on the connector ( the secret ) introduced a bug, when worker_cache is enabled. The secret will not be initialized, and that may creates all kind of serious problems. Not sure what's the best solution ( not using cache_size will impact the performance ), but we could create a separate download with the (fixed) native code and rebuild the binaries. Thanks Mike for finding the bug, my apologies for causing the problem. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Native Connector problems
One of the last changes on the connector ( the secret ) introduced a bug, when worker_cache is enabled. The secret will not be initialized, and that may creates all kind of serious problems. Could you detail the problem ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Native Connector problems
The problem is that the default cache size is one and in the ajp_init function in jk_ajp_common.c we return from inside of an if when we initialize the cache so the secrect member of the structure never gets initialized. This caused some GPFs in certain cases on some of my builds. I've checked in the fix. All I did was move the line that initializes secret up above the if statement. Remy, would it be possible to relabel jk_ajp_common.c rev. 1.24 as the rev for tomcat_402? I've built and tested this fix on NetWare and the resolved my GPFs and bad behavior talking to older installations of Tomcat (i.e. 3.3). I was able to use the same module to talk to Tomcat 4.0.2 and Tomcat 3.3 from the same instance of the web server. I love it when a plan comes together :-) Mike Anderson [EMAIL PROTECTED] 02/12/02 05:19PM One of the last changes on the connector ( the secret ) introduced a bug, when worker_cache is enabled. The secret will not be initialized, and that may creates all kind of serious problems. Could you detail the problem ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Native Connector problems
On Tue, 12 Feb 2002, Mike Anderson wrote: The problem is that the default cache size is one and in the ajp_init The problem is that I spent too much time writing java code. I didn't see the return statement, the deep if() have confused me. If you ever see any commit (from me) that late in a release cycle - make sure you -1 it, regardless of how usefull it may look. Peer review seems to work well, but it needs more time. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: Native Connector problems
Hi, I just ran into a problem with the loadbalancing stuff. I built mod_jk.so from the 4.0.2 connector package and replaced my mod_jk.so (TC3.3 Version) with this one in apache/libexec (1.3.19). By just changing a link back and forth between the two versions, I tested our TC3.3 based application against the two versions of mod_jk. If this is not enough and I am missing something, please let me know. Otherwise exactly the same setup All works perfectly with the new mod_jk when I use normal ajp13 workers (one webapp), but fails when I use a loadbalancing worker pointing to another webapp on a different Tomcat instance. I do not have the mod_jk.log here at home. Will send it in a couple of hours when I am in the office. What else would be required for debugging? Note, We use the loadbalancer just for switching tomcats. Only one instance of the two loadbalanced Tomcats is active most of the time. (by changing the lbvalue) Thanks, Hans -Ursprungliche Nachricht- Von: Mike Anderson [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 13. Februar 2002 02:17 An: [EMAIL PROTECTED] Betreff: RE: Native Connector problems The problem is that the default cache size is one and in the ajp_init function in jk_ajp_common.c we return from inside of an if when we initialize the cache so the secrect member of the structure never gets initialized. This caused some GPFs in certain cases on some of my builds. I've checked in the fix. All I did was move the line that initializes secret up above the if statement. Remy, would it be possible to relabel jk_ajp_common.c rev. 1.24 as the rev for tomcat_402? I've built and tested this fix on NetWare and the resolved my GPFs and bad behavior talking to older installations of Tomcat (i.e. 3.3). I was able to use the same module to talk to Tomcat 4.0.2 and Tomcat 3.3 from the same instance of the web server. I love it when a plan comes together :-) Mike Anderson [EMAIL PROTECTED] 02/12/02 05:19PM One of the last changes on the connector ( the secret ) introduced a bug, when worker_cache is enabled. The secret will not be initialized, and that may creates all kind of serious problems. Could you detail the problem ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
