On 7/12/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
I did take a look at this earlier and didn't see any issues right away. (surprise surprise) The pooling aspect of components shouldn't have the result that you are having. Ie the pool size might reflect the greatest # of concurrent users you've had at any given instance but shouldn't just incrementally grow and grow.
That's exactly what I thought... It doesn't make sense to me that there are so many instances created. If you are interested at looking (a little more) at the issue, I could probably provide you a heap dump and you would be able to navigate in all the instances with jhat... Someone skilled with tapestry internals might understand right away what is going wrong. I just had a quick look at Tapestry code, where is that pool localed? What would prevent ognl to create a new expression binding everytime? Would this be the ognl expression cache? Also by looking at tapestry source code, in ognlbindingfactory, for each new binding there is a IComponent reference that is passed. If there is a pool for IComponents, how can a component be removed of the pool if ExpressionBinding still has a hold on the component reference? The expression cache isn't doing anything bad though. I did check to be sure
and didn't see any indicators of leakage possibilities. This sounds like something I could spend weeks on with only the result of learning more about hivemind/ognl than I'd like. Not sure what to do about it......
Thanks,
Henri.
