How can I tell if my .war file is finished deploying in Tomcat?
We write automated installs to deploy .war files in Tomcat. Now we just add a wait or delay in the install script, and it's just a guess how long...( 30, 60, 120, seconds? ) based on timing a manual deployment.
Is there some kind of query or command to tell if it finished deploying?
It seems to me that the the Tomcat deploy task for Ant is synchronous, but I could be wrong. Is that what you're using for the automated installs? If so, then when the task finishes, the app should be deployed. However, if it's asynchronous, then I suppose you could have a simple servlet to act as a ping. Then you could hit that every few seconds until you got back a 200 status.
Joined: Dec 18, 2012
Thank you for the reply.
We are using Flexera Software InstallShield for automated installations onto Tomcat 7.
Autodeploy is set to true, and the .war is copied into webapps folder and Tomcat automatically deploys the .war.
At that point, we have our arbitrary timer set, but even still, we don't know if it's finished deploying.
Is there a better way than using autodeploy? Is it better practice to use a script?
How do we ping for a 200 status? And what is a 200 status?
Oh, I meant you could write and deploy a PingServlet in your webapp, which would implement doGet() by writing out "OK" (or anything) to the output stream. If you hit that servlet and get back the "OK" string, you'd know it was deployed. You could also check for a 200 status code, which means OK. (See javax.servlet.http.HttpServletResponse to see a list of values for response codes.) Unfortunately, I don't know specifically how to do any of that with InstallShield. It might be worth finding out if that Ant task actually is synchronous, and if it is, invoke an Ant build that includes it as part of your install process.
The definitive way to determine if a war has finished deploying and the webapp has started is to look in the catalina.out log. A message will be logged.
In operational terms, Tomcat will respond to a request made to that webapp in various ways depending on how far along it is.
When a war is not yet deployed, requests will return (almost) instantly with a "404 Not Found" error from Tomcat.
When a was is just beginning to come online you may see a 5xx error. Your Mileage May Vary.
Once the webapp has deployed but is still starting, requests will hang until the webapp has come online, then be processed. Assuming that the client hasn't timed out first, of course.
You can gain some insight into why things happen the way they do by understanding that when you send an HTTP request to Tomcat, it's Tomcat itself that accepts the request. Tomcat then scans its list of active Contexts to see if the incoming URL matches against one of them. If so, the request is queued up to be sent to one of the associated webapp's various request processors. Which processor gets the request depends on 1) pattern matches against definitions in the webapp's web.xml, 2) matches against JSPs 3) no match on the preceeding, resulting in the work being sent to the default servlet that's part of Tomcat.
Customer surveys are for companies who didn't pay proper attention to begin with.
here i was thinking that waiting for the CPU utilization to go back down on Task Manager was good enough. Its worked for last couple hundred times at least. It also helps you understand that you do not want a single core CPU on production :P.
Lamini Braveheart wrote:here i was thinking that waiting for the CPU utilization to go back down on Task Manager was good enough. Its worked for last couple hundred times at least. It also helps you understand that you do not want a single core CPU on production :P.
Having multiple cores on production servers hasn't always been an option for me. As for monitoring CPU utilitization, that only works if the webapp doesn't immediately launch startup code that consumes more CPU than the deployment process itself does. One idiot wrote an app that battered CPU and database for 35 minutes after deploying. I finally had to rewrite the startup code just to be able to get decent test turnaround.