tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pid *" <>
Subject Re: parallel deployment activation of new version
Date Thu, 19 Apr 2012 07:35:16 GMT
On 19 Apr 2012, at 08:07, "" <> wrote:

> Christoph Maser <> wrote:
>> Am Donnerstag, den 12.04.2012, 14:02 +0100 schrieb
>>> Christoph Maser <> 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


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.


> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message