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 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 resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
