tags:

views:

47

answers:

2

I have a J2EE application front-ended by a bunch of GWT pages. When the server is starting up, it is possible that these static pages can be accessed before the services required to implement the GWT RPC calls (database etc) are available. I wondering what the best approach is to prevent a user accessing this static content before these services become available.

For the purpose of this exercise, assume that there is an isInitialized() method somewhere. I am happy with either a page displaying an error message or simply refusing the connection.

+4  A: 

A servlet filter (i.e. an implementation of javax.servlet.Filter) would the obvious choice here. It can consult your isInitialized() method and redirect/forward to a "not yet available" page somewhere. The url-pattern of the filter in web.xml would be chosen to catch the specific requests you want to guard.

skaffman
A: 

Is your app clustered behind a load balancer? If so, then your issue is really that you must prevent the load balancer from directing traffic to any server instance that is not fully initialized. You could create an AmIReady servlet which checks out server's state and then returns an appropriate response code (200 or 503?). Bind this to /checkstatus or whatever, and make your load balancer use this URL as a health check.

If you are doing sticky load balancing, the idea proposed by @skaffman would likely work presuming that you are really setting your cache settings for *no-cache.js files to no-cache. However, that approach would result in a period of time where a user would get an error response from the initializing server when a good response could have been obtained from another server in the cluster (presuming, of course, that you are able to do round-robin deployments to avoid downtime. And that your session caching strategies allow users to flow seamlessly between servers, etc., etc.

ShabbyDoo
A good point, however no we are not load balancing in this case.
Dean Povey