felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls" <karlpa...@gmail.com>
Subject Re: [jira] Commented: (FELIX-827) URLHandlers does not restore the previous URLStreamHandlerFactory after stopping Felix
Date Tue, 02 Dec 2008 08:28:17 GMT
> What a mess! For now we just have to restart Tomcat every time we deploy a
> new build. We may not find a better solution, since even if all of Felix's
> leaks are fixed, it's been pointed out to me that other libraries such as
> commons-logging have reloading problems too. Oh well.

Care to share your insides with us as well? Maybe there is something
we can do...

Regarding leaks in general, we do take them seriously and will try to
trace down and fix them. In case of  the URLHandlers you are running
in a known limitation of the implementation I didn't have time to
refactor yet. For the time being, try to get my patch working and see
whether that makes a difference.

regards,

Karl

> Thanks,
> Tim
>
> On Dec 1, 2008, at 5:04 PM, Niclas Hedhman wrote:
>
>> Tim,
>> also beware that Sun's JVM caches a lot of the stuff in the resource
>> management system, and IIRC URLStreamHandlerFactories belong in that
>> category too, at least if used via the java.net.handler.pkgs system
>> property. Perhaps the setURLStreamHandlerFactory is better behaved,
>> but I suggest to check the actual sources to be sure.
>>
>>
>> Cheers
>> Niclas
>>
>> On Tue, Dec 2, 2008 at 1:41 AM, Tim Moore (JIRA) <jira@apache.org> wrote:
>>>
>>>  [
>>> https://issues.apache.org/jira/browse/FELIX-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652219#action_12652219
>>> ]
>>>
>>> Tim Moore commented on FELIX-827:
>>> ---------------------------------
>>>
>>> Karl,
>>>
>>> Thanks for your response. I'll test the patch. Unfortunately, the problem
>>> with memory leaks in webapps is rather bad, because class objects contain a
>>> reference to their classloader, and the classloader then contains references
>>> to every class that it loaded. So if even one class object reference leaks
>>> from a webapp classloader to a parent loader, the entire classloader cannot
>>> be collected. This makes it very important for anything in a webapp that
>>> registers itself with an object in the system classloader to unregister when
>>> the webapp is unloaded. These problems can be very tricky to track down, and
>>> until every single leak is patched, the problem will remain.
>>>
>>>> URLHandlers does not restore the previous URLStreamHandlerFactory after
>>>> stopping Felix
>>>>
>>>> --------------------------------------------------------------------------------------
>>>>
>>>>               Key: FELIX-827
>>>>               URL: https://issues.apache.org/jira/browse/FELIX-827
>>>>           Project: Felix
>>>>        Issue Type: Improvement
>>>>        Components: Framework
>>>>  Affects Versions: felix-1.2.1
>>>
>>> , felix-1.4.0
>>>>
>>>>          Reporter: Tim Moore
>>>>          Assignee: Karl Pauls
>>>>           Fix For: felix-1.4.1
>>>>
>>>>       Attachments: felix-827.patch, leak.patch,
>>>> test-felix-handler-1.0-SNAPSHOT.jar, test-felix-handler.zip
>>>>
>>>>
>>>> I'm running Felix embedded inside a webapp, running in Tomcat.
>>>> Tomcat installs its own URLStreamHandlerFactory. Felix swaps it out
>>>> correctly when I start it, and seems to delegate properly. When the webapp
>>>> is unloaded, however, and it stops Felix, it does not restore the previous
>>>> implementation, but rather leaves the existing URLHandlers instance
>>>> installed. Then, if I try to redeploy the webapp without restarting the JVM,
>>>> I get errors, because Tomcat automatically sets the URLHandlers class's
>>>> static members to null when it unloads the webapp. (see
>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=41939)
>>>> I've tested this on 1.2.1 and 1.4.0, and both versions have this
>>>> problem.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>
> --
> Tim Moore
> Atlassian Plugin Developer
>
>
>
>
>



-- 
Karl Pauls
karlpauls@gmail.com

Mime
View raw message