1

Currently, Glassfish Server sits behind a Apache HTTPD server. Glassfish server provides business applications along with static content.

The idea is to allow Apache HTTPD server to provide static content instead of Glassfish providing them as in the current design. Static content are files in the order of a few MB's . The primary reason this isnt the original design is because files should be allowed to be downloaded only if the STATE of the Glassfish deployed application is ENABLED (Service Unlock - SOA architecture).

I have a few ideas to implement this. At the moment I need affirmation if this is doable.

Assume the static content is provided by Apache HTTPD, below are the ideas to implement

1) If there is communication possible between HTTPD and Glassfish (mod_jk?). If yes, can I pass custom messages from glassfish to HTTPD indicating the state of application to allow/disallow the clients access to static content. I dont want to depend on HTTP responses (404) as that ties up my glassfish resourse (thread-pool) as the number of clients requesting the download can be in the range of thousands. The idea is that Glassfish indicates a YES/NO from time to time (whenever change occurs) to HTTPD server. Depending on that state, apache writes down that state somewhere. When ever a client requests for the static content, HTTPD refers to the written state and takes decision if it can allow the clients access to the static files.

2) The next option is a simple ProxyPass mechanism from HTTPD and depending on the HTTP responses from the Glassfish, decision is taken if client can have access to static files. As stated earlier, this ties up my Glassfish resourses and isn't desirable.

3) I use JMS middleware to pass messages between glassfish and clients (different client). Can Apache listen to JMS queue. If yes, I can then pass Yes/No messages between Glassfish and HTTPD to Allow/Deny client requestd for static files.

4) Configure Glassfish server to provide static content by tuning the thread pool (as per current implementation). Least desirable.

0 Answers0