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.
