Re: Releasing JK 1.2.19
On 9/14/06, Rainer Jung <[EMAIL PROTECTED]> wrote: David Rees wrote: OK. I would propose that adding a new feature that allows you to map all requests matching .*;jsessionid=.* to mod_jk would be a worthy feature. I am willing to work on a patch if no mod_jk developers are interested. Should I open an enhancement request? Please open a Bugzilla for an enhancement request. Thanks for pointing it out. In case you missed my comment to bug 40151, I can confirm that the new functionality provided in 1.2.19 works great. Thanks! -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.19
Build works on i5/OS v5R3, I'm waiting now for its activation by my IT team. Regards 2006/9/15, Henri Gomez <[EMAIL PROTECTED]>: No problem for me on Linux Suse SLES 9 and Power PC. Checking iSeries build now >2006/9/14, Rainer Jung <[EMAIL PROTECTED]>: > Please open a Bugzilla for an enhancement request. > > Thanks for pointing it out. > > David Rees wrote: > > On 9/14/06, Mladen Turk <[EMAIL PROTECTED]> wrote: > >> > So what do you do when you have multiple virtualhosts mapped to > >> > different workers? > >> > >> Please don't split hair :) > >> > >> In that case use the JkMount/JkUnMount combinations > >> to separate the resources served by Httpd. > > > > Less than ideal, but this whole issue doesn't happen that often anyway. > > > >> I can agree with you that selecting default > >> worker for that situation would be a nice thing to > >> have, but it's definitely not a bug. > > > > OK. I would propose that adding a new feature that allows you to map > > all requests matching .*;jsessionid=.* to mod_jk would be a worthy > > feature. I am willing to work on a patch if no mod_jk developers are > > interested. Should I open an enhancement request? > > > >> > Also, SetHandler jakarta-servlet isn't documented anywhere that I can > >> > find, otherwise I would have tried it sooner. > >> > >> Right, it is not documented. Not sure why, because it was > >> out there for a long time. > > > > Should I open an issue in bugzilla for it? I am also willing to write > > something up if no mod_jk developers have the time. > > > > Thanks, > > -Dave > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > kippdata informationstechnologie GmbH > Bornheimer Str. 33a > 53111 Bonn > > Tel.: 0228/98549-0 > Fax: 0228/98549-50 > www.kippdata.de > === > kippdata informationstechnologie GmbH > Bornheimer Str. 33a > D-53111 Bonn > > Tel.: +49/0228/98549-0 > Fax: +49/0228/98549-50 > www.kippdata.de > > - > 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: Releasing JK 1.2.19
No problem for me on Linux Suse SLES 9 and Power PC. Checking iSeries build now 2006/9/14, Rainer Jung <[EMAIL PROTECTED]>: Please open a Bugzilla for an enhancement request. Thanks for pointing it out. David Rees wrote: > On 9/14/06, Mladen Turk <[EMAIL PROTECTED]> wrote: >> > So what do you do when you have multiple virtualhosts mapped to >> > different workers? >> >> Please don't split hair :) >> >> In that case use the JkMount/JkUnMount combinations >> to separate the resources served by Httpd. > > Less than ideal, but this whole issue doesn't happen that often anyway. > >> I can agree with you that selecting default >> worker for that situation would be a nice thing to >> have, but it's definitely not a bug. > > OK. I would propose that adding a new feature that allows you to map > all requests matching .*;jsessionid=.* to mod_jk would be a worthy > feature. I am willing to work on a patch if no mod_jk developers are > interested. Should I open an enhancement request? > >> > Also, SetHandler jakarta-servlet isn't documented anywhere that I can >> > find, otherwise I would have tried it sooner. >> >> Right, it is not documented. Not sure why, because it was >> out there for a long time. > > Should I open an issue in bugzilla for it? I am also willing to write > something up if no mod_jk developers have the time. > > Thanks, > -Dave > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- kippdata informationstechnologie GmbH Bornheimer Str. 33a 53111 Bonn Tel.: 0228/98549-0 Fax: 0228/98549-50 www.kippdata.de === kippdata informationstechnologie GmbH Bornheimer Str. 33a D-53111 Bonn Tel.: +49/0228/98549-0 Fax: +49/0228/98549-50 www.kippdata.de - 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: Releasing JK 1.2.19
Please open a Bugzilla for an enhancement request. Thanks for pointing it out. David Rees wrote: On 9/14/06, Mladen Turk <[EMAIL PROTECTED]> wrote: > So what do you do when you have multiple virtualhosts mapped to > different workers? Please don't split hair :) In that case use the JkMount/JkUnMount combinations to separate the resources served by Httpd. Less than ideal, but this whole issue doesn't happen that often anyway. I can agree with you that selecting default worker for that situation would be a nice thing to have, but it's definitely not a bug. OK. I would propose that adding a new feature that allows you to map all requests matching .*;jsessionid=.* to mod_jk would be a worthy feature. I am willing to work on a patch if no mod_jk developers are interested. Should I open an enhancement request? > Also, SetHandler jakarta-servlet isn't documented anywhere that I can > find, otherwise I would have tried it sooner. Right, it is not documented. Not sure why, because it was out there for a long time. Should I open an issue in bugzilla for it? I am also willing to write something up if no mod_jk developers have the time. Thanks, -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- kippdata informationstechnologie GmbH Bornheimer Str. 33a 53111 Bonn Tel.: 0228/98549-0 Fax: 0228/98549-50 www.kippdata.de === kippdata informationstechnologie GmbH Bornheimer Str. 33a D-53111 Bonn Tel.: +49/0228/98549-0 Fax: +49/0228/98549-50 www.kippdata.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.19
On 9/14/06, Mladen Turk <[EMAIL PROTECTED]> wrote: > So what do you do when you have multiple virtualhosts mapped to > different workers? Please don't split hair :) In that case use the JkMount/JkUnMount combinations to separate the resources served by Httpd. Less than ideal, but this whole issue doesn't happen that often anyway. I can agree with you that selecting default worker for that situation would be a nice thing to have, but it's definitely not a bug. OK. I would propose that adding a new feature that allows you to map all requests matching .*;jsessionid=.* to mod_jk would be a worthy feature. I am willing to work on a patch if no mod_jk developers are interested. Should I open an enhancement request? > Also, SetHandler jakarta-servlet isn't documented anywhere that I can > find, otherwise I would have tried it sooner. Right, it is not documented. Not sure why, because it was out there for a long time. Should I open an issue in bugzilla for it? I am also willing to write something up if no mod_jk developers have the time. Thanks, -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.19
David Rees wrote: Have you tried? SetHandler jakarta-servlet The worker used will be the first one in worker.list if you explicitly set the handler. So what do you do when you have multiple virtualhosts mapped to different workers? Please don't split hair :) In that case use the JkMount/JkUnMount combinations to separate the resources served by Httpd. I can agree with you that selecting default worker for that situation would be a nice thing to have, but it's definitely not a bug. Also, SetHandler jakarta-servlet isn't documented anywhere that I can find, otherwise I would have tried it sooner. Right, it is not documented. Not sure why, because it was out there for a long time. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.19
On 9/13/06, Mladen Turk <[EMAIL PROTECTED]> wrote: David Rees wrote: > I'm using this config in Apache: > > JkMount /*.jsp tomcatlb > > JkMount tomcatlb > Have you tried? SetHandler jakarta-servlet The worker used will be the first one in worker.list if you explicitly set the handler. So what do you do when you have multiple virtualhosts mapped to different workers? Also, SetHandler jakarta-servlet isn't documented anywhere that I can find, otherwise I would have tried it sooner. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.19
David Rees wrote: Ok, I'm pretty sure this is a real bug (though not a new one, mod_jk back to 1.2.15 behaves the same). This not an bug. I'm using this config in Apache: JkMount /*.jsp tomcatlb JkMount tomcatlb Have you tried? SetHandler jakarta-servlet The worker used will be the first one in worker.list if you explicitly set the handler. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.19
Ok, I'm pretty sure this is a real bug (though not a new one, mod_jk back to 1.2.15 behaves the same). I'm using this config in Apache: JkMount /*.jsp tomcatlb JkMount tomcatlb The goal of this example to have Tomcat serve all .jsp files and URL which looks like it has been rewritten with the session id. But the problem is that the LocationMatch directive isn't parsed the same by mod_jk as it is by Apache. You would expect that any URL which matches the LocationMatch would immediately be sent to Tomcat, but instead it appears to behave the same as a JkMount directive. So the above configuration is handled the same as JkMount /*.jsp tomcatlb JkMount "/.*;jsessionid=.*" tomcatlb Naturally since mod_jk strips off the jsessionid before matching, it doesn't work. Not to mention that the Apache Regexp doesn't work the same as a JkMount expression. For example, JkMount /*.jsp tomcatlb does not behave the same as JkMount tomcatlb but does behave the same as JkMount tomcatlb This is very confusing if you were trying to use the LocationMatch for example to set some other Apache directives you would not get the result you expected. The only way I know to get mod_jk to send *.jsp and anything with ;jsessionid in it to Tomcat and let Tomcat serve the other content is to do a JkMount /* and then JkUnMount for all file types you can think of, but that is a big hassle when you have a lot of virtualhosts to configure and still doesn't quite let you do what you really want. Bug 40151 is related to this issue. It would be nice if you could set a JkMountJSessionId directive that would automatically match any URLs which look like they have been URL rewritten. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.19
On 9/13/06, Rainer Jung <[EMAIL PROTECTED]> wrote: Anything in the mod_jk log? [error] ajp_service::jk_ajp_common.c (1879): (pepper7) Connecting to tomcat failed. Tomcat is probably not started or is listening on the wrong port Tomcat is running, the mod_jk log level was set to error You mean "first hit" after restart, or after a time of inactivity? I typically have this happen in the morning after Tomcat has restarted. I wonder if I'm running into a ping/pong timeout which occurs because Tomcat has been swapped out after nightly activity. I should try increasing that value (set to 500ms). In fact after thinking about it, I am just about 100% sure this is the problem (machine could use more memory, I see swap space in use and swap page/in activity when I received the error), thanks for pointing me in the right direction. 1.2.19-dev looks good then, except for 1 minor nit: It would be nice if jkstatus had descriptions for the values of Act and Stat columns. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.19
This is not a known feature. Anything in the mod_jk log? You mean "first hit" after restart, or after a time of inactivity? Platform? Server version? The new svn HEAD code gives the ability to log useful state info of the LB in the access logs, so you can more easily find out, how often and when these things happen. Until we release 1.2.19 you can find the most recent code under http://people.apache.org/~rjung/mod_jk-1.2.19-dev/ and some hints about this new logging feature on http://people.apache.org/~rjung/mod_jk-1.2.19-dev/docs/config/apache.html (look for "mod_log_config" there). We should continue this on the users list. Regards, Rainer David Rees wrote: Anyone else seeing a problem where sometimes the first hit returns a 503 and shows the worker recovering? Waiting for the recovery period to go and the worker is ok. This is a simple load balanced worker with only one child worker. Unfortunately I can't reliably reproduce this, it seems to happen most often with the first hit in the morning after sitting idle all night. 1.2.18 behaves the same... -Dave - 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: Releasing JK 1.2.19
Anyone else seeing a problem where sometimes the first hit returns a 503 and shows the worker recovering? Waiting for the recovery period to go and the worker is ok. This is a simple load balanced worker with only one child worker. Unfortunately I can't reliably reproduce this, it seems to happen most often with the first hit in the morning after sitting idle all night. 1.2.18 behaves the same... -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.19
I updated the testing snapshot tarball after Peters report, and set the link to a more durable http://people.apache.org/~rjung/mod_jk-1.2.19-dev/ Regards, Rainer Peter Rossbach wrote: Hi Mladen and Rainer, sometimes I see a small time a strange artifact: start apache look at jkstatus all worker show state N/A all backend tomcats are stopped access a URL look at jkstatus all worker show state ERR access URL again all worker show state REC (very nice new feature) start tomcat access URL one worker OK other worker state REC stop tomcat access URL again all worker show state REC (cool) I thing first report is a bootstrap problem, but I can find it :-) regards Peter Am 13.09.2006 um 16:07 schrieb Rainer Jung: In preparation of release 1.2.19 of tomcat-connnectors (including mod_jk) I made the actual HEAD of the code available for download and testing under http://people.apache.org/~rjung/mod_jk-1.2.19-442987/ This is not an official release, but another opportunity to give the code a quick try before we cut the release. The release is being planned for tagging during saturday. Regards, Rainer Rainer Jung wrote: Yes, I'm willing and I've got time to cut a release during the weekend. I'll put a HEAD tarball on people.apache.org during the next hour and announce that on tomcat-dev, so that interesting parties have another chance of giving it a quick try (since wwe've got again a lot of changes since the last quality check). Tagging will be done during Saturday. Is there a need to announce precise timings, or are there no more pending changes? Regards, Rainer Mladen Turk wrote: Hi, Seems we had a pretty long test window. Can we schedule the release by the end of this week? Rainer, are you still willing to act as the RM for 1.2.19? Regards, Mladen. - 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] - 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: Releasing JK 1.2.19
Hi Mladen and Rainer, sometimes I see a small time a strange artifact: start apache look at jkstatus all worker show state N/A all backend tomcats are stopped access a URL look at jkstatus all worker show state ERR access URL again all worker show state REC (very nice new feature) start tomcat access URL one worker OK other worker state REC stop tomcat access URL again all worker show state REC (cool) I thing first report is a bootstrap problem, but I can find it :-) regards Peter Am 13.09.2006 um 16:07 schrieb Rainer Jung: In preparation of release 1.2.19 of tomcat-connnectors (including mod_jk) I made the actual HEAD of the code available for download and testing under http://people.apache.org/~rjung/mod_jk-1.2.19-442987/ This is not an official release, but another opportunity to give the code a quick try before we cut the release. The release is being planned for tagging during saturday. Regards, Rainer Rainer Jung wrote: Yes, I'm willing and I've got time to cut a release during the weekend. I'll put a HEAD tarball on people.apache.org during the next hour and announce that on tomcat-dev, so that interesting parties have another chance of giving it a quick try (since wwe've got again a lot of changes since the last quality check). Tagging will be done during Saturday. Is there a need to announce precise timings, or are there no more pending changes? Regards, Rainer Mladen Turk wrote: Hi, Seems we had a pretty long test window. Can we schedule the release by the end of this week? Rainer, are you still willing to act as the RM for 1.2.19? Regards, Mladen. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.19
In preparation of release 1.2.19 of tomcat-connnectors (including mod_jk) I made the actual HEAD of the code available for download and testing under http://people.apache.org/~rjung/mod_jk-1.2.19-442987/ This is not an official release, but another opportunity to give the code a quick try before we cut the release. The release is being planned for tagging during saturday. Regards, Rainer Rainer Jung wrote: Yes, I'm willing and I've got time to cut a release during the weekend. I'll put a HEAD tarball on people.apache.org during the next hour and announce that on tomcat-dev, so that interesting parties have another chance of giving it a quick try (since wwe've got again a lot of changes since the last quality check). Tagging will be done during Saturday. Is there a need to announce precise timings, or are there no more pending changes? Regards, Rainer Mladen Turk wrote: Hi, Seems we had a pretty long test window. Can we schedule the release by the end of this week? Rainer, are you still willing to act as the RM for 1.2.19? Regards, Mladen. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.19
Yes, I'm willing and I've got time to cut a release during the weekend. I'll put a HEAD tarball on people.apache.org during the next hour and announce that on tomcat-dev, so that interesting parties have another chance of giving it a quick try (since wwe've got again a lot of changes since the last quality check). Tagging will be done during Saturday. Is there a need to announce precise timings, or are there no more pending changes? Regards, Rainer Mladen Turk wrote: Hi, Seems we had a pretty long test window. Can we schedule the release by the end of this week? Rainer, are you still willing to act as the RM for 1.2.19? Regards, Mladen. - 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]
