JeanNiBee wrote: > Hi > > I have two application contexts, /RAM and /UO.
Context initialization is serial. If you try starting in the wrong order you will be out of luck. Tomcat won't start serving requests until all the contexts have started. You can't control the order the apps start in. It will be arbitrary. You could try the following: Add a filter to OU that is mapped to /*. It checks for RAM, it RAM isn't running the requests are blocked. Once RAM is running it lets requests through and then your Servlet inits. You could write your filter such that once it detects RAM is running, it doesn't check RAM again. Mark > > OU needs to have RAM running before it can do anything as I have startup > code (Fired during init of my servlet) in UO that needs to access RAM. > > The problem I have is that when I do startup the Tomcat container, the > minute my 'init code' get's executed in UO, it locks the whole container > mainly because it's using HTTP calls to RAM to access it's information > (which hasn't started up yet). > > Classic (as I see it) chicken and the egg scenario, UO can't start because > RAM isn't started and the whole container is locking HTTP connections > because all the app contexts aren't started. > > Is there any way that I can have these two application contexts exist > peacefully without causing this condition? Can I force the load order of app > contexts (though using multiple service setups in the server.xml? > > Or am I looking at having (and due to business reasons this is 'almost' not > a solution) two installations of tomcat each managing one of the apps. > > Note: > I have tried the following. > > 1. "Ping" servlet in UO that pings RAM And sleeps for X seconds until RAM is > running. After 5 tries and 2 mintues (10x more than RAM needs in a normal > situation to start) I call destroy on the servlet and kill the startup > process. Running on the same container / servlet actually causes the LOCK on > the very first HTTP "ping" to RAM and a subsequent stopping of Tomcat load > altogether (system.exit call) > 2. Two <Service> configuration elements in the server.xml each managing it's > own resources. This option worked better as UO would ping / sleep > successfully for its' configured iterations, but RAM would never be started > until UO was finished it's tries. If I left the 'die' code in UO then of > course nothing loaded (as mentioned abovein point #1), but if I took out the > die code, RAM loaded AFTER UO no problem. I would LOVE UO to be last if > possible. > > It seems I can never get RAM to load before UO. (or at least let it keep > loading while UO sleeps on it's ping requests. > > Thanks. > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
