P.S. Without knowing completely how hivemind/this is handling pooling my first gut instinct reaction is that it might not necessarily be a pooling problem? I'm not saying it isn't, but if you look at it in really simplistic terms the pool size should only reflect the highest number of concurrent requests you have had come in.
If you see your pool sizes growing and growing incrementally over time with no direct correlation to # of concurrent requests then you may have something. In summary, if your app is just "running out of memory" over time then I'd venture to guess there might possibly be another problem that you haven't thought of yet. If your app really is crashing once a day as you've mentioned on the users list you may as well try swapping out jvm/servlet container implementations? (Ie maybe ~gasp~ jdk 6 and jetty? ) On 7/25/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
Anything having to do with object pools/ognl caching/etc would probably be something I wouldn't approach very lightly. This would be something I'd have to feel like I had a very complete and thorough understanding of before attempting any changes.. Luckily we've already moved to TestNG, so at least writing unit tests with threading/parallelizing in mind won't be very hard. On 7/25/06, Henri Dupre <[EMAIL PROTECTED]> wrote: > > On 7/25/06, Henri Dupre < [EMAIL PROTECTED]> wrote: > > > > I just had a look again at a heap from our app and one common source > to > > all the components instances is the object pool. > > http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/services/impl/ObjectPoolImpl.java?view=markup > > > > > The code says "** This ia a minimal implementation, one that has no > > concept of automatically removing unused pooled > > * objects. Eventually, it will also register for notifications about > > general cache cleaning." * > > ** > > This sounds scary... Does anyone know exactly what the role of this > class > > is? Somehow this class can hold references to page instances (which > hold > > component instances). > > Could this pool use weakreferences or at least have a limit? > > > > Ok I found myself most of the answers in the code... The pool is used > for > storing pages and engines instances. > I would suggest creating 2 pools: 1 pool with a limit and/or weak > references > for the pages and another persistent one (though I'm not exactly sure > how > the engine/local instances work). This would help tapestry adjust to the > server load: the number of pages in the pool is never going to decrease > with > the load with the current pool system. > Also the PageSource code would need hardly any modification to work with > WeakReferences. > > Thanks, > > Henri. > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
-- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
