My initial testing indicates that the leak indeed has been fixed in 4.0!
I'll have to get back on this once I have our real application up and
running in 4.0


Mattias Jiderhamn wrote (2009-04-02 11:23):
> Scott Ferguson wrote (2009-03-30 18:20):
>> On Mar 30, 2009, at 3:54 AM, Mattias Jiderhamn wrote:
>>> After drawing the conclusion below, it isn't very far away to realize
>>> it probably has to do with some static (i.e. class loader specific)
>>> member of EnvironmentClassLoader.
>>> And just as I thought, the heart of the problem is
>>>   private static EnvironmentLocal<ArrayList<AddLoaderListener>>
>>> _addLoaderListeners
>>> More specifically, if line 234 of com.caucho.server.resin.Resin is
>>> commented out, the leak is removed (assuming my
>>> HttpRequest._invocation patch is also applied)
>>>    // Environment.addChildLoaderListener(new WebBeansAddLoaderListener())
>>> Scott, you said the WebBeans caches were not to blame because they
>>> are classloader local. Well, it seems something about this
>>> classloader locality isn't working the way it should, doesn't it...?
>>> Do you have enough info to try to fix this in a future (hopefully
>>> soon to be released) 3.1 release?
>> In the early work with 4.0, I'd cleaned a number of dead links
>> (primarily WebBeans, but also some JMX).  I believe the current 4.0
>> still has a few left, so I'll need to run a final pass at the end of
>> the release cycle.
> Are you saying this won't be fixed in the 3.1 branch? I'm assuming the
> 4.0 production release is still months ahead?
> Could we provide you any additional information to change your mind...?

resin-interest mailing list

Reply via email to