You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mladen Turk <mt...@apache.org> on 2006/09/13 13:40:51 UTC
Releasing JK 1.2.19
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by David Rees <dr...@gmail.com>.
On 9/13/06, Rainer Jung <ra...@kippdata.de> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by Rainer Jung <ra...@kippdata.de>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by David Rees <dr...@gmail.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by Rainer Jung <ra...@kippdata.de>.
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: dev-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Peters observation concerning mod_jk forced recovery
Posted by Rainer Jung <ra...@kippdata.de>.
Thanks for the report:
The new forced recovery feature tried to do that in case all workers
went into ERROR state in two places: after request processing and during
maintenance.
After request processing it relied on a condition that evaluated to
false in all cases, so it basically never happened there, only during
maintenance.
I hope my three latest commits fixed it. So if all workers are really in
error during request processing, the request gets a second chance on
them, indepependently from the point in time when the workers went into
error. If tomcat is still down/in error, after request processing all
workers will end up being in error.
For the maintenance part, I changed it from checking during every
process maintenance, to checking only during global maintenance. If the
request part is correct, it should never be necessary during
maintenance, since the request part already handles it, whenever it's
necessary. Dropping the maintenance part might only result in slightly
different logging messages and a different view in jkstatus. But even
without the maintenance part, recovery should happen immediate, whenever
a request comes in and all workers are in error.
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: dev-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by Peter Rossbach <pr...@objektpark.de>.
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: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Releasing JK 1.2.19
Posted by Rainer Jung <ra...@kippdata.de>.
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: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by Rainer Jung <ra...@kippdata.de>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by Henri Gomez <he...@gmail.com>.
Build works on i5/OS v5R3, I'm waiting now for its activation by my IT team.
Regards
>2006/9/15, Henri Gomez <he...@gmail.com>:
> No problem for me on Linux Suse SLES 9 and Power PC.
>
> Checking iSeries build now
>
> >2006/9/14, Rainer Jung <ra...@kippdata.de>:
> > Please open a Bugzilla for an enhancement request.
> >
> > Thanks for pointing it out.
> >
> > David Rees wrote:
> > > On 9/14/06, Mladen Turk <mt...@apache.org> 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: dev-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> > --
> > 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: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by Henri Gomez <he...@gmail.com>.
No problem for me on Linux Suse SLES 9 and Power PC.
Checking iSeries build now
>2006/9/14, Rainer Jung <ra...@kippdata.de>:
> Please open a Bugzilla for an enhancement request.
>
> Thanks for pointing it out.
>
> David Rees wrote:
> > On 9/14/06, Mladen Turk <mt...@apache.org> 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: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
>
> --
> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by David Rees <dr...@gmail.com>.
On 9/14/06, Rainer Jung <ra...@kippdata.de> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by Rainer Jung <ra...@kippdata.de>.
Please open a Bugzilla for an enhancement request.
Thanks for pointing it out.
David Rees wrote:
> On 9/14/06, Mladen Turk <mt...@apache.org> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
--
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by David Rees <dr...@gmail.com>.
On 9/14/06, Mladen Turk <mt...@apache.org> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by Mladen Turk <mt...@apache.org>.
David Rees wrote:
>>
>> Have you tried?
>>
>> <LocationMatch "/.*;jsessionid=.*">
>> SetHandler jakarta-servlet
>> </LocationMatch>
>>
>> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by David Rees <dr...@gmail.com>.
On 9/13/06, Mladen Turk <mt...@apache.org> wrote:
> David Rees wrote:
> > I'm using this config in Apache:
> >
> > JkMount /*.jsp tomcatlb
> > <LocationMatch "/.*;jsessionid=.*">
> > JkMount tomcatlb
> > </LocationMatch>
>
> Have you tried?
>
> <LocationMatch "/.*;jsessionid=.*">
> SetHandler jakarta-servlet
> </LocationMatch>
>
> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by Mladen Turk <mt...@apache.org>.
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
> <LocationMatch "/.*;jsessionid=.*">
> JkMount tomcatlb
> </LocationMatch>
>
Have you tried?
<LocationMatch "/.*;jsessionid=.*">
SetHandler jakarta-servlet
</LocationMatch>
The worker used will be the first one in
worker.list if you explicitly set the handler.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Releasing JK 1.2.19
Posted by David Rees <dr...@gmail.com>.
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
<LocationMatch "/.*;jsessionid=.*">
JkMount tomcatlb
</LocationMatch>
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
<LocationMatch "/.*\.jsp">
JkMount tomcatlb
</LocationMatch>
but does behave the same as
<LocationMatch "/*.jsp">
JkMount tomcatlb
</LocationMatch>
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org