One approach that I was considering was to have a servlet with the servlet mapping url pattern match exactly as the file name that will hold the data. If the instance on which a request lands is the one instance where the file exists, it should serve the file or else the request goes to the servlet with the same url pattern as the file, which will then fetch the file from the one instance where the file exists and return that in response.
Ulf Dittmer wrote:Sounds complicated.
Ulf Dittmer wrote:Sounds complicated. Why does it matter whether the file is served by a servlet or directly? Why not always serve it via the servlet? If performance is of utmost concern, the file contents can be cached in memory after it has been fetched initially, thereby avoiding disk access on all instances.
If you have an Apache in front of the app server, you could put the file into a directory that is handled by Apache, thus avoiding the cluster issue altogether.
Roberto Perillo wrote:So the problem is that there is some data that is generated externally, and since your application is in a clustered environment, it might be handled more than one time (i.e. the number of servers in the cluster), and if you save this set of data as a file, then it would exist in only one of the servers, and if a server different from the one the file is saved in handles a request, then the file won't be found.
Roberto Perillo wrote:Well, what you can do is, since this set of data is handled on regular intervals, you could create a Quartz job and configure it to work in a clustered environment
Dinkar Chaturvedi wrote:The file contents are going to be a JSON format text which I would like to serve as is. Can Quartz be configured to fire the job to write a file instead of a database?