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.



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:
> [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:
> > [EMAIL PROTECTED] Behalf Of *Michael Brunton-Spall
> > *Sent:* Tuesday 16 October 2007 11:32
> > *To:*
> > *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 mailing list
resin-interest mailing list

Reply via email to