You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christoph Maser <Ch...@1und1.de> on 2012/04/12 08:42:42 UTC
parallel deployment activation of new version
Hi
is there a way to externally influence the switch between versions with
the new parallel deployment method. As I understand it tomcat
automatically switches to the new version for new requests as soon as
the context with the new version is started. Instead I would like to
manually control wich version is the preferred active one.
Regards
Chris
Re: parallel deployment activation of new version
Posted by Pid * <pi...@pidster.com>.
On 19 Apr 2012, at 08:07, "markt@apache.org" <ma...@apache.org> wrote:
> Christoph Maser <Ch...@1und1.de> wrote:
>
>> Am Donnerstag, den 12.04.2012, 14:02 +0100 schrieb markt@apache.org:
>>> Christoph Maser <Ch...@1und1.de> wrote:
>>>
>>>> Do you see any chance a request for feature in that direction would
>> be
>>>> accpeted?
>>>
>>> Right now, no. I don't see a requirement that isn't met by the
>> existing implementation. If there was a use case that wasn't completely
>> off the wall that couldn't be met then it would get looked at. Actual
>> implementation would depend on an assessment of benefit against
>> complexity.
>>>
>>> Mark
>>>
>>
>> Well the idea is to have additional saftey measures that check if the
>> webapp is in the desired state after the context is started. This is
>> done by sending queries against the webapp for standard pages or
>> debug/health-status pages that the webapp provides.
>
> There is a logic problem with that requirement. Requests without sessions can't be sent to the app until after the health checks are complete and some switch flicked but the health checks are requests without sessions.
>
>> A reason to do not let the context startup fail in a case where the
>> webapp is in a non desired state is that you loose access to those
>> debug/healt-status pages the webapp provides and you end up searching
>> for the causes in the logfiles.
>
> However, this is probably the simplest solution. Put whatever info is in those pages in your error message on failure.
>
>> Antoher point are loadbalancers. Often loadbalancers have the
>> possibiity
>> to check if a "real Server" is "alive" by sending a request to a
>> defined
>> URL. So as enother safty maesure one might check this URL too before
>> switching. This one should of course never happen, thats what proper
>> testing is for, but in real life strangest things happen.
>
> I can see what you are trying to do but the logic problem needs resolving.
>
> One possible solution:
> - add a flag to a context that enables/disables it for parallel deployment
> - provide a mechanism (tbd) to change this flag
> - deploy apps with this flag enabled by default
> - fake the session ID to route the health check to the new app
>
> I haven't looked at the mapper to see how complex this might be and what the performance impact is. Compared to a better error message when startup fails, my initial impression is that this feature wouldn't be worth implementing.
Especially when:
ROOT/myapp1/healthcheck <- always reports app load failure
ROOT/myapp2/healthcheck
ROOT/myapp3/healthcheck
/myapp1/healthcheck
/myapp2/healthcheck
/myapp3/healthcheck
would achieve the same.
A Filter in ROOT on /*/healthcheck would also work.
Better than both is to use the JMX API where you can see the presence
and state of each component.
p
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: parallel deployment activation of new version
Posted by ma...@apache.org.
Christoph Maser <Ch...@1und1.de> wrote:
>Am Donnerstag, den 12.04.2012, 14:02 +0100 schrieb markt@apache.org:
>> Christoph Maser <Ch...@1und1.de> wrote:
>>
>> >Do you see any chance a request for feature in that direction would
>be
>> >accpeted?
>>
>> Right now, no. I don't see a requirement that isn't met by the
>existing implementation. If there was a use case that wasn't completely
>off the wall that couldn't be met then it would get looked at. Actual
>implementation would depend on an assessment of benefit against
>complexity.
>>
>> Mark
>>
>
>Well the idea is to have additional saftey measures that check if the
>webapp is in the desired state after the context is started. This is
>done by sending queries against the webapp for standard pages or
>debug/health-status pages that the webapp provides.
There is a logic problem with that requirement. Requests without sessions can't be sent to the app until after the health checks are complete and some switch flicked but the health checks are requests without sessions.
>A reason to do not let the context startup fail in a case where the
>webapp is in a non desired state is that you loose access to those
>debug/healt-status pages the webapp provides and you end up searching
>for the causes in the logfiles.
However, this is probably the simplest solution. Put whatever info is in those pages in your error message on failure.
>Antoher point are loadbalancers. Often loadbalancers have the
>possibiity
>to check if a "real Server" is "alive" by sending a request to a
>defined
>URL. So as enother safty maesure one might check this URL too before
>switching. This one should of course never happen, thats what proper
>testing is for, but in real life strangest things happen.
I can see what you are trying to do but the logic problem needs resolving.
One possible solution:
- add a flag to a context that enables/disables it for parallel deployment
- provide a mechanism (tbd) to change this flag
- deploy apps with this flag enabled by default
- fake the session ID to route the health check to the new app
I haven't looked at the mapper to see how complex this might be and what the performance impact is. Compared to a better error message when startup fails, my initial impression is that this feature wouldn't be worth implementing.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: parallel deployment activation of new version
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 4/25/12 4:21 PM, Pid wrote:
> On 25/04/2012 15:57, Christopher Schultz wrote:
>> Pid,
>>
>> On 4/23/12 9:50 PM, Pid wrote:
>>> On 23/04/2012 15:06, Christopher Schultz wrote:
>>>> Christoph,
>>>>
>>>> On 4/22/12 11:55 AM, Christoph Maser wrote:
>>>>> Chris,
>>>>
>>>>> Am Donnerstag, den 19.04.2012, 18:21 +0200 schrieb
>>>>> Christopher Schultz:
>>>>>> Christoph,
>>>>>>
>>>>>> What about the webapp itself performing its own
>>>>>> health-check as a last step of deployment, and throwing
>>>>>> an exception (thereby preventing Tomcat from bringing it
>>>>>> into service) if things aren't in working order?
>>>>
>>>>> this is the obvious way to do it as it is now. As I said
>>>>> before that way one looses the access to the wapps status
>>>>> pages.
>>>>
>>>> So you want the webapp both up (for status) and down (for
>>>> traffic) at the same time? Tomcat certainly can't manage that
>>>> for you.
>>>>
>>>> If you need "status" on a failed-deployment, why not dump it
>>>> to a file or something like that?
>>
>>> Or use JMX rather than HTTP to acquire status information.
>>
>> In theory that sounds good, but the webapp needs to be deployed
>> in order to interrogate it via JMX. Once it's deployed, it's in
>> service (even if it's broken) and the system falls apart.
>
> Which 'system falls apart'?
Sorry... shorthand for "new version is in service, and broken, and yet
it accepts new sessions which seems to be contrary to the OP's
requirements".
> JMX provides an alternative route to determine application status
> that is not impacted by whether the app is up or down.
Sure.
> If the app is not deployed there will be no associated MBeans.
>
> If it is deployed but not running the status attribute of the
> WebModule MBean will indicate this.
Right. Are you suggesting that the webapp can fail deployment and
still be interrogated via MBeans? That's essentially what I'm
suggesting: have the webapp fail on deployment. OP is saying he wants
the webapp to deploy successfully so it can be interrogated via HTTP.
I think we both agree that is both a bad idea and not really workable
without big (and honestly unnecessary) changes to Tomcat.
> An HTTP connection is much less reliable and trying to do what the
> OP is asking is unlikely to provide a universally reliable result.
>
> If the app is well behaved then it could start up enough to report
> it's health, given some components not starting properly - but I
> think the OP is asking for something else.
We'll see.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+YY+QACgkQ9CaO5/Lv0PAVZQCgq8cEG4d5/GlSP3htC2vlwnTi
kwUAmwaZoGcvPaCfUqw4rwJQ3he3OOpp
=IRZv
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: parallel deployment activation of new version
Posted by Pid <pi...@pidster.com>.
On 25/04/2012 15:57, Christopher Schultz wrote:
> Pid,
>
> On 4/23/12 9:50 PM, Pid wrote:
>> On 23/04/2012 15:06, Christopher Schultz wrote:
>>> Christoph,
>>>
>>> On 4/22/12 11:55 AM, Christoph Maser wrote:
>>>> Chris,
>>>
>>>> Am Donnerstag, den 19.04.2012, 18:21 +0200 schrieb Christopher
>>>> Schultz:
>>>>> Christoph,
>>>>>
>>>>> What about the webapp itself performing its own health-check
>>>>> as a last step of deployment, and throwing an exception
>>>>> (thereby preventing Tomcat from bringing it into service) if
>>>>> things aren't in working order?
>>>
>>>> this is the obvious way to do it as it is now. As I said
>>>> before that way one looses the access to the wapps status
>>>> pages.
>>>
>>> So you want the webapp both up (for status) and down (for
>>> traffic) at the same time? Tomcat certainly can't manage that for
>>> you.
>>>
>>> If you need "status" on a failed-deployment, why not dump it to a
>>> file or something like that?
>
>> Or use JMX rather than HTTP to acquire status information.
>
> In theory that sounds good, but the webapp needs to be deployed in
> order to interrogate it via JMX. Once it's deployed, it's in service
> (even if it's broken) and the system falls apart.
Which 'system falls apart'?
JMX provides an alternative route to determine application status that
is not impacted by whether the app is up or down.
If the app is not deployed there will be no associated MBeans.
If it is deployed but not running the status attribute of the WebModule
MBean will indicate this.
An HTTP connection is much less reliable and trying to do what the OP is
asking is unlikely to provide a universally reliable result.
If the app is well behaved then it could start up enough to report it's
health, given some components not starting properly - but I think the OP
is asking for something else.
p
--
[key:62590808]
Re: parallel deployment activation of new version
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 4/23/12 9:50 PM, Pid wrote:
> On 23/04/2012 15:06, Christopher Schultz wrote:
>> Christoph,
>>
>> On 4/22/12 11:55 AM, Christoph Maser wrote:
>>> Chris,
>>
>>> Am Donnerstag, den 19.04.2012, 18:21 +0200 schrieb Christopher
>>> Schultz:
>>>> Christoph,
>>>>
>>>> What about the webapp itself performing its own health-check
>>>> as a last step of deployment, and throwing an exception
>>>> (thereby preventing Tomcat from bringing it into service) if
>>>> things aren't in working order?
>>
>>> this is the obvious way to do it as it is now. As I said
>>> before that way one looses the access to the wapps status
>>> pages.
>>
>> So you want the webapp both up (for status) and down (for
>> traffic) at the same time? Tomcat certainly can't manage that for
>> you.
>>
>> If you need "status" on a failed-deployment, why not dump it to a
>> file or something like that?
>
> Or use JMX rather than HTTP to acquire status information.
In theory that sounds good, but the webapp needs to be deployed in
order to interrogate it via JMX. Once it's deployed, it's in service
(even if it's broken) and the system falls apart.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+YEPUACgkQ9CaO5/Lv0PB+PQCcChgwpeR0ODTcnn8+RiOHFdaR
mOwAoJcHd4fb6hTUf+Zy3OkpgfV2G97o
=o1DV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: parallel deployment activation of new version
Posted by Pid <pi...@pidster.com>.
On 23/04/2012 15:06, Christopher Schultz wrote:
> Christoph,
>
> On 4/22/12 11:55 AM, Christoph Maser wrote:
>> Chris,
>
>> Am Donnerstag, den 19.04.2012, 18:21 +0200 schrieb Christopher
>> Schultz:
>>> Christoph,
>>>
>>> What about the webapp itself performing its own health-check as a
>>> last step of deployment, and throwing an exception (thereby
>>> preventing Tomcat from bringing it into service) if things aren't
>>> in working order?
>
>> this is the obvious way to do it as it is now. As I said before
>> that way one looses the access to the wapps status pages.
>
> So you want the webapp both up (for status) and down (for traffic) at
> the same time? Tomcat certainly can't manage that for you.
>
> If you need "status" on a failed-deployment, why not dump it to a file
> or something like that?
Or use JMX rather than HTTP to acquire status information.
p
--
[key:62590808]
Re: parallel deployment activation of new version
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christoph,
On 4/22/12 11:55 AM, Christoph Maser wrote:
> Chris,
>
> Am Donnerstag, den 19.04.2012, 18:21 +0200 schrieb Christopher
> Schultz:
>> Christoph,
>>
>> What about the webapp itself performing its own health-check as a
>> last step of deployment, and throwing an exception (thereby
>> preventing Tomcat from bringing it into service) if things aren't
>> in working order?
>
> this is the obvious way to do it as it is now. As I said before
> that way one looses the access to the wapps status pages.
So you want the webapp both up (for status) and down (for traffic) at
the same time? Tomcat certainly can't manage that for you.
If you need "status" on a failed-deployment, why not dump it to a file
or something like that?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+VYfIACgkQ9CaO5/Lv0PAkGgCfYpk2VWmy2sYRmVQXSQu/pLZS
SskAoJnS1aUGHBMZZk+mZY82Zie9aG2x
=Czs4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: parallel deployment activation of new version
Posted by Christoph Maser <ch...@1und1.de>.
Chris,
Am Donnerstag, den 19.04.2012, 18:21 +0200 schrieb Christopher Schultz:
> Christoph,
>
> What about the webapp itself performing its own health-check as a last
> step of deployment, and throwing an exception (thereby preventing
> Tomcat from bringing it into service) if things aren't in working order?
this is the obvious way to do it as it is now. As I said before that way
one looses the access to the wapps status pages.
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: parallel deployment activation of new version
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christoph,
On 4/19/12 2:34 AM, Christoph Maser wrote:
> Well the idea is to have additional saftey measures that check if
> the webapp is in the desired state after the context is started.
> This is done by sending queries against the webapp for standard
> pages or debug/health-status pages that the webapp provides.
What about the webapp itself performing its own health-check as a last
step of deployment, and throwing an exception (thereby preventing
Tomcat from bringing it into service) if things aren't in working order?
That would seem to be easier than re-working Tomcat to allow *true*
parallel deployment where the client gets to pick the version of the
webapp to contact.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+QO4IACgkQ9CaO5/Lv0PAjtwCgizwupYsPsMk78IuzyNxarw9w
wcEAoKbmk7iCipLAN5u3uIeSRdCLma0h
=OC9u
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: parallel deployment activation of new version
Posted by Christoph Maser <Ch...@1und1.de>.
Am Donnerstag, den 12.04.2012, 14:02 +0100 schrieb markt@apache.org:
> Christoph Maser <Ch...@1und1.de> wrote:
>
> >Do you see any chance a request for feature in that direction would be
> >accpeted?
>
> Right now, no. I don't see a requirement that isn't met by the existing implementation. If there was a use case that wasn't completely off the wall that couldn't be met then it would get looked at. Actual implementation would depend on an assessment of benefit against complexity.
>
> Mark
>
Well the idea is to have additional saftey measures that check if the
webapp is in the desired state after the context is started. This is
done by sending queries against the webapp for standard pages or
debug/health-status pages that the webapp provides.
A reason to do not let the context startup fail in a case where the
webapp is in a non desired state is that you loose access to those
debug/healt-status pages the webapp provides and you end up searching
for the causes in the logfiles.
Antoher point are loadbalancers. Often loadbalancers have the possibiity
to check if a "real Server" is "alive" by sending a request to a defined
URL. So as enother safty maesure one might check this URL too before
switching. This one should of course never happen, thats what proper
testing is for, but in real life strangest things happen.
Chris
Re: parallel deployment activation of new version
Posted by ma...@apache.org.
Christoph Maser <Ch...@1und1.de> wrote:
>Do you see any chance a request for feature in that direction would be
>accpeted?
Right now, no. I don't see a requirement that isn't met by the existing implementation. If there was a use case that wasn't completely off the wall that couldn't be met then it would get looked at. Actual implementation would depend on an assessment of benefit against complexity.
Mark
>Chris
>
>Am Donnerstag, den 12.04.2012, 09:40 +0100 schrieb Mark Thomas:
>> The only control you have is by ensuring that the version you want to
>be used by default has the highest version number.
>>
>> Mark
>>
>> Christoph Maser <Ch...@1und1.de> wrote:
>>
>> >Hi
>> >
>> >is there a way to externally influence the switch between versions
>with
>> >the new parallel deployment method. As I understand it tomcat
>> >automatically switches to the new version for new requests as soon
>as
>> >the context with the new version is started. Instead I would like to
>> >manually control wich version is the preferred active one.
>> >
>> >
>> >Regards
>> >Chris
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>--
>Christoph Maser
>
>
>1&1 Internet AG - IT Operations Mail & Media Homepage
>Frankfurter Ring 115a · DE-80807 München
>Telefon: +49 89 14339-528
>christoph.maser@1und1.de
>
>Amtsgericht Montabaur / HRB 6484
>Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Robert
>Hoffmann, Andreas Hofmann, Markus Huhn, Hans-Henning Kettler, Dr.
>Oliver
>Mauss, Jan Oetjen
>Aufsichtsratsvorsitzender: Michael Scheeren
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: parallel deployment activation of new version
Posted by Christoph Maser <Ch...@1und1.de>.
Do you see any chance a request for feature in that direction would be
accpeted?
Chris
Am Donnerstag, den 12.04.2012, 09:40 +0100 schrieb Mark Thomas:
> The only control you have is by ensuring that the version you want to be used by default has the highest version number.
>
> Mark
>
> Christoph Maser <Ch...@1und1.de> wrote:
>
> >Hi
> >
> >is there a way to externally influence the switch between versions with
> >the new parallel deployment method. As I understand it tomcat
> >automatically switches to the new version for new requests as soon as
> >the context with the new version is started. Instead I would like to
> >manually control wich version is the preferred active one.
> >
> >
> >Regards
> >Chris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
Christoph Maser
1&1 Internet AG - IT Operations Mail & Media Homepage
Frankfurter Ring 115a · DE-80807 München
Telefon: +49 89 14339-528
christoph.maser@1und1.de
Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Robert
Hoffmann, Andreas Hofmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver
Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren
Re: parallel deployment activation of new version
Posted by Mark Thomas <ma...@apache.org>.
The only control you have is by ensuring that the version you want to be used by default has the highest version number.
Mark
Christoph Maser <Ch...@1und1.de> wrote:
>Hi
>
>is there a way to externally influence the switch between versions with
>the new parallel deployment method. As I understand it tomcat
>automatically switches to the new version for new requests as soon as
>the context with the new version is started. Instead I would like to
>manually control wich version is the preferred active one.
>
>
>Regards
>Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: parallel deployment activation of new version
Posted by Christoph Maser <Ch...@1und1.de>.
Am Donnerstag, den 12.04.2012, 14:29 -0400 schrieb Christopher Schultz:
> It's worth mentioning that requests bound to sessions that were
> associated with the "old" version will continue to be serviced by the
> old version of the webapp.
>
> You said "new requests" but "new sessions" is more accurate.
>
> -chris
>
>
You are right of course that is what I meant.
Chris
Re: parallel deployment activation of new version
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christoph,
On 4/12/12 2:42 AM, Christoph Maser wrote:
> is there a way to externally influence the switch between versions
> with the new parallel deployment method. As I understand it tomcat
> automatically switches to the new version for new requests as soon
> as the context with the new version is started.
It's worth mentioning that requests bound to sessions that were
associated with the "old" version will continue to be serviced by the
old version of the webapp.
You said "new requests" but "new sessions" is more accurate.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+HHwMACgkQ9CaO5/Lv0PBv/QCfa4sDQYyAFF11l8Bd6tfwYFv7
eZYAoI7MDMJbw3aUVsTqtrb+b2nwYvlx
=g3yu
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org