On Oct 16, 2007, at 8:00 AM, Michael Brunton-Spall wrote:

Andre,

The plan is that there will be a seperate application, run at regular intervals that will poll the database, look for data that has been modified recently, and it would "press" the pages. This would provide us with potentially out of date, but valid pages for all of our core content, available all the time. That "cache" of static files would be being constantly updated, up until a database failure, at which point we would like to start serving from it. We can't serve from it in normal times because much of our data relies on complex decaching algorithms, and providng randomised datasources to our view renderers, and it would be technically infeasable at this point in time to manage the decaching of the static pages when somethign that caused the caching of that page happens.

Could you just use RequestDispatcher.forward() to Resin's FileServlet? You might want to add a <path-mapping> or <rewrite-file- path> to change the real-path for the FileServlet.

-- Scott


Thanks

Michael

On 10/16/07, Dalen, Andre van <[EMAIL PROTECTED]> wrote:
Michael,

If you experience a catastrofic database failure, you probably don't have the data to generate the pages, so redirecting to some kind of out-of-order informartion would seem appropriate as it will be too late to start building your static pages.

You could keep the setup I described dynamic by never saving the generated pages to the filesystem until load gets above a threshold, and removing them in a background thread when the load goes under a low watermark.

That would mean resin always fails to find the page incurring processing overhead for the lookup and redirecting to the 404 handler servlet under normal circumstances. This makes the solution sub-optimal in my view,
as a result of promoting an exception to be the rule.

Another approach would be leaving your application as it is, placing a caching proxy in front of it, and playing with the cache headers in the response. Under normal circumstances you provide your pages with no-cache headers, while under load you insert cache headers specifying lifetimes proportional to the load on the system (ie, medium load yields short cacheing periods and heavy load yield long cacheing periods.)

regards, Andre

 -----Original Message-----
From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] Behalf Of Michael Brunton-Spall
Sent: Tuesday 16 October 2007 13:35
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Serving static files dynamically from resin

Andre,

That sounds almost perfect, except that we don't want for the system to behave that way except in very unusual circumstances.

So we need to be able to switch into using this mode only when either we have a catastrophic database failure, or when we are suffering unusually high load (such as 10 to 100 times our normal load).

Is there a way to disable / defer the processing of the static file until after our servlet has had a chance to examine it, and to totally disable that static file processing when we don't need it.

Thanks

Michael

On 10/16/07, Dalen, Andre van <[EMAIL PROTECTED]> wrote:
Hi Michael,

Instead of mapping a servlet url to static content (I'm assuming that that is what you are trying to do) you can also get the client to request the url for what the static pages would be and map the servlet that generates the
static content to the 404 error handler.

In this setup the static file is always tried first, and when it doesn't exist the generating servlet gets the
chance to built it from scratch in a on-demand basis.

The servlet can generate the static file, save it in the web-app content folders and then stream the generated page to the client that triggered the servlet. All subsequent requests find the files in the content (cache) folders
and resin will serve those.

One issue to watch out for is multiple requests coming into the servlet for the same page, you can either keep a collection with generation jobs and synchronise threads on it picking up the generated page and streaming it when it is ready, or just generate the first few requests in paralel and making sure only the first gets to save it to
the filesystem.

Hope this helps, Andre
-----Original Message-----
From: [EMAIL PROTECTED] [mailto: resin-interest- [EMAIL PROTECTED] Behalf Of Michael Brunton-Spall
Sent: Tuesday 16 October 2007 11:32
To: resin-interest@caucho.com
Subject: [Resin-interest] Serving static files dynamically from resin

Hi there,

I've googled for this, and can't seem to find anyone who wants to do the same thing, so I figured you guys would be the best source of information.

We run a very large website, which is generated dynamically from resin, and we are looking at technical failover solutions. We believe that there are certain cases where our workload could increase dramatically, and we believe that our application will not withstand such a large onslaught of requests.

Looking at our architecture, we believe that serving static pages will be possible under very high traffic loads, so we are writing a system that will "press" copies of dynamic pages to an html cache when they are modified. Under these extreme circumstances we would like to have a module that instead of doing all of our processing and going to the database, instead looks in a static directory of html files, and if there is a static file present for the requested url, serves that instead.

However, I am having difficulty finding how it is possible to get resin to serve a static file in response to a url, where we will have to do some mapping to translate the url to the file location.

We could write our own file server, but given that resins performance is pretty good for serving static files, we would much rather hook into resins file serving capabilites.


Michael Brunton-Spall

_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest



_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Reply via email to