Howard Lewis Ship wrote: > On 10/26/05, Fernando Padilla <[EMAIL PROTECTED]> wrote: > >>A few weeks ago we had a memory leak that we thought was caused by >>Tapestry, but was in fact caused by us confusing Tapestry. We had gone >>and overriden the getLocale() method in the BasePage to return a "new >>Locale( "en_US" )" which totally confused Tapestry's PagePool, so that >>it never recognized the PagePool key and recompiled every page on every >>request.. we discovered this after we had it in production.. arg. We >>simply replaced it to return "Locale.US", and it was fine. > > Interesting; perhaps we should key on the Locale's toString() to avoid > this problem?
I haven't put the time to figure out what went wrong here.. I know that we should have done "new Locale( "en", "US" )" instead of what we did, but I don't know how what we did could have broken it, because I believe the .eqauls() was still behaving.. unless Tapestry was doing a "==" which I didn't find in the code.. The toString() isn't a bad idea.. >>-- PagePool lacking -- >> >>It seems like the number of pages compiled by Tapestry has a permanent >>impact on the memory footprint for another reason. It seems like >>Tapestry's PagePool does not release "idle" pages. (** This is only what >>it looks like through profiler, haven't confirmed in code; anyone want >>to confirm? **) Thus the PagePool will grow in order to handle an flash >>flood of concurrent requests, but will not release those pages after the >>abnormal load dissipates. >> > > I decided to leave the page pool mechanics very simple, since it is so > easy for the underlying HiveMind service to be overridden with > something smarter. A complete solution would purge out unused page > instances after some period of time (Tapestry 3 did this, but the > thread it spawned to act as a janitor caused lots of problems). I totally agree, better a good attempt at something simple, than a lousy implementation - no matter how fancy. >>-- PagePool enhancement -- >> >>Anyhow, maybe one of us using Tapestry for high profile production >>systems should take some time to make a better PagePool implementation: >>- more tuning parameters >>- release of unused/idle pages >>- limit the unbounded compile of pages based on concurrent requests >> - maybe have a slow growth pattern with blocking, limiting the >> concurrent request handling on flash mobs, but avoiding the real >> possibility of out of memory situations.. > > I think an ideal page pool would properly track how many of each page > has been allocated and set an upper limit on the number of page > instances; would block for a short period of time, waiting for a page > instance to become available, and would eventually fail with some kind > of "application busy" message. > > Suddenly, the API for ObjectPool and PageSource gets a bit more > complicated to handle these cases. In a desperate situation, how do > you handle rendering an exception page if now exception page instances > are available? I guess that, eventually, you send an HTTP 500 > response. And though I've had this idea for a few weeks I still haven't been able to put any time towards that.. So I encourage anyone else who might want to play with it! I also have some other enterprise ideas, like integrating lastmodified throughout pages and components to help with caching, and you can even do subpage caching at the point. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
