tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ma...@apache.org
Subject Re: parallel deployment activation of new version
Date Thu, 19 Apr 2012 06:58:28 GMT
Christoph Maser <Christoph.Maser@1und1.de> wrote:

>Am Donnerstag, den 12.04.2012, 14:02 +0100 schrieb markt@apache.org:
>> Christoph Maser <Christoph.Maser@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


Mime
View raw message