Scott, That sounds exactly like what I need, thanks, I'll go and lok around to see how that would work, and let you all know if it works or not.
Michael On 10/16/07, Scott Ferguson <[EMAIL PROTECTED]> wrote: > > > 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: > > [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] > > > ]*On 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 > >
_______________________________________________ resin-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/resin-interest
