On 19 Apr 2012, at 08:07, "ma...@apache.org" <ma...@apache.org> wrote:
> Christoph Maser <christoph.ma...@1und1.de> wrote: > >> Am Donnerstag, den 12.04.2012, 14:02 +0100 schrieb ma...@apache.org: >>> Christoph Maser <christoph.ma...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
