Can a web application be configured for auto-restart in the event it goes down for some reason?
The idea is to make the web application Highly Available ,so that practically there's little or no down time for the same.
What could be other possible approaches? I was wondering if JMX could serve any purpose? Need to check if JMX exposes web application controlling ( start/stop/restart) capabilities. In case it doesn't have those,what could be the possible designs to achieve the same?
A cron job with either webget or a command line Java applcation should be able to do this.
Have it hit a page in your app ever n minutes. If you don't get a status 200 back, you'll know something went wrong. At that point, your app could either restart the web application by making a web call to the Tomcat manager, or if it's running on the same box as Tomcat, restart Tomcat itself from the command line.
Well,actually I'm working on similar lines by designing a portable(and hence Java coded) watchdog which would ping a component of the web app running on tomcat at regular intervals.
The inherent complexity of the problem lies in the fact that in case the response received is not as expected/erroneous, we need to figure out what the error could be attributed to
1> Tomcat not running
2> Tomcat process running,but with few threads (may be the TCP connection listener thread 8080)not running
3> The web application is not running
4> The web application is in an inconsistent state
1> Could be easily detected by checking the existence of the tomcat server process,but detecting 2> could be tricky.
Again 3> and 4> are equivalent from an application control perspective,as in both the cases,the web app needs to be restarted.
So that requires putting some thoughts on how to detect 2>. This is important because the watchdog should not be led to interpret that Tomcat is running fine just because the corresponding process is running,and therefore proceed to restart the webapp,instead of restarting the Tomcat.
-Any thoughts/comments would be highly appreciated! [ July 25, 2008: Message edited by: Ajay Saxena ]
The inherent complexity of the problem lies in the fact that in case the response received is not as expected/erroneous, ...
That doesn't really tell us much. When you say response, what exactly do you mean? Are you making a web request a resource running under Tomcat? If so, are you looking at the response code? If so, what are you getting back? What were you expecting? How are you making this request?
Joined: Nov 13, 2006
That doesn't really tell us much.
When you say response, what exactly do you mean?
I mean the HTTP response obtained by the watchdog
Are you making a web request a resource running under Tomcat?
Yes, the watchdog will fire a web request periodically to the resource(a servlet) that would form a part of the monitored web app running on Tomcat
If so, are you looking at the response code? If so, what are you getting back?
Well, these things haven't been finalized yet,and I'm yet to look into how to make use of the response code to detect the errors . It's good that you pointed them out
What were you expecting?
I might sound really stupid here, but I'm still not decided on this as I need to know what I should expect in this case to interpret an error free response. Excuse my little experience with web response handling.
How are you making this request?
As already said, it's a plain web request wrapped in a HTTPurlconnection from the watchdog [ July 26, 2008: Message edited by: Ajay Saxena ]
A 200 response code means that everything is good. 404 is page not found, 500 is a server error.
No response means that the server is down altogether or that there is a network problem between the client and server.
If you download and install the LiveHTTPHeaders plugin for firefox, you can see the response codes and HTTP headers going back and forth between your browser and whatever server you're hitting. It's a good tool for getting your head around the way HTTP works.