Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of pid@pidster.com designates
 209.85.160.45 as permitted sender)
References: <15D3435601304A49A5E13D0825711B6128CC5706@EXCHANGE07.webde.local>
 <c9852e00-8f22-4a9a-99b7-7543ab14d743@email.android.com>
 <15D3435601304A49A5E13D0825711B6128CC570C@EXCHANGE07.webde.local>
 <efd47547-82e2-4d89-b0e3-76747acb8a6c@email.android.com>
 <15D3435601304A49A5E13D0825711B6128CC5740@EXCHANGE07.webde.local>
 <2be74d4f-f0ca-42e2-850a-b856def1449c@email.android.com>
From: "Pid *" <pid@pidster.com>
In-Reply-To: <2be74d4f-f0ca-42e2-850a-b856def1449c@email.android.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 19 Apr 2012 08:35:16 +0100
Message-ID: <-7644235873111289499@unknownmsgid>
Subject: Re: parallel deployment activation of new version
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: text/plain; charset=UTF-8

On 19 Apr 2012, at 08:07, "markt@apache.org" <markt@apache.org> wrote:

> 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.

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