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: [email protected]
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
[email protected]
http://maillist.caucho.com/mailman/listinfo/resin-interest
_______________________________________________
resin-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/resin-interest
_______________________________________________
resin-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/resin-interest
_______________________________________________
resin-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/resin-interest
