Tomcat doesn't start processing requests until the server has started completely (which includes all web apps). To accept and then block incoming requests until then is a minuscule task that shouldn't have a noticeable performance impact. Is this an actual problem, or an imagined one?
Joined: Nov 11, 2011
Thanks for dropping by the post. It is indeed an actual program. The UI is separate from the application and we have interfaces implemented to support the interaction.
From the application one can send requests to the server, not knowing whether the server has completely started up or not. These requests are not served by the server .
This leads to unnecessary exceptions and an incomplete handling of the requests. Is there a way to check whether the server has been deployed successfully and only than cater to the requests?
Joined: Sep 21, 2011
There's nothing wrong with exceptions that indicate that a required resource (the server) isn't available. You just need to catch and handle them properly, so that the user knows what's going on.
If you wanted to go to great length, you should be able to use JMX to connect to the Tomcat instance remotely and inquire about its status. If Tomcat hasn't started fully, they may not work either, though, and would in any case open up Tomcat to remote JMX connections - not really something you'd want to do on a production server.
Joined: Nov 11, 2011
As I confirmed earlier as well, the UI app is not provided to us. Due to incomplete deployment, when a server gets a request from UI, the server response is misleading.
Handling exceptions can be thought of but there can be a number of cases to handle then. I will look into this option but I do need a way to block incoming requests until complete deployment happens.
I have been assigned this task. Had I owned this app, I might have looked for some other way(may be exception handling). But the need of the hour is to provide a solution for blocking the requests.
In actuality, there's no such thing as "server deploys completely". Within a J2EE webapp server, individual webapps can be started, stopped, deployed and undeployed pretty much at will.
In your particular case, the primary distinction is that you're only concerning yourself with whether or not a given set of apps is running, but not, for example, whether one of them has crashed and is no longer running at some point after the server had started them.
It's sloppy programming to create apps that fail if they cannot interact with external services. Unfortunately, this is an era where "Always the Low Price" and "Git 'er Dun!" trump good application design and implementation, so there are a lot of them about.
I suppose that a way could be found to gimmick up Tomcat so that it would bounce requests until otherwise directed. However, if I was entrusted with such a fragile environment, my first impulse would be to simply switch off the Tomcat HTTP and HTTPS ports at the firewall until the system had stabilized. That can be done relatively easily by an administrator without the need to come up with specialized code.
Customer surveys are for companies who didn't pay proper attention to begin with.