I found the same problem in tomcat 5.5.17. But not found this problem in tomcat 5.5.14 I used jdk1.5.0_7.
เมื่อ พ. 2006-07-12 เวลา 00:40 -0400, Henri Dupre เขียนว่า: > 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.
