Return-Path: Delivered-To: apmail-felix-dev-archive@www.apache.org Received: (qmail 93394 invoked from network); 2 Dec 2008 08:29:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Dec 2008 08:29:48 -0000 Received: (qmail 58982 invoked by uid 500); 2 Dec 2008 08:29:59 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 58940 invoked by uid 500); 2 Dec 2008 08:29:59 -0000 Mailing-List: contact dev-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@felix.apache.org Delivered-To: mailing list dev@felix.apache.org Received: (qmail 58929 invoked by uid 99); 2 Dec 2008 08:29:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2008 00:29:59 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of karlpauls@gmail.com designates 209.85.221.20 as permitted sender) Received: from [209.85.221.20] (HELO mail-qy0-f20.google.com) (209.85.221.20) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2008 08:28:31 +0000 Received: by qyk13 with SMTP id 13so3382539qyk.22 for ; Tue, 02 Dec 2008 00:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=l8ckrFKFwW8ZkfSvhIIX4zN8BKtZ1FjkRXN36xvBPwc=; b=IFSjTOH/OUtaro/B1As8R/u9+lf557nwhkkNFffJUn0ae7jZVaXRh0oVlI079aOR1M NoG43H5eJdURDbuO+daLeBQ19fn0odUiTK/5UK6162Fha739x0hkApgX1dOAeiDZXLfp R6NBpVL4B1wrwZ+PINi4nQZln4gV3W+OGaBbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Bm9QstxsV9AWRYeKGzamglNY7ET8qWemWn1BUWjtU45w9/vSQ2mlfBrA7PVHUMVrvR wXmAp8NCQoZDMDwOlWFNA4pqAccITXkoK7gJboc3TZeZsYj6Y3attYu0bZyjrveim0zO +XhsLTug9fSXmxJKBjcalKoD7Y1yeRpmiT0CI= Received: by 10.214.215.3 with SMTP id n3mr11103930qag.243.1228206497787; Tue, 02 Dec 2008 00:28:17 -0800 (PST) Received: by 10.215.66.19 with HTTP; Tue, 2 Dec 2008 00:28:17 -0800 (PST) Message-ID: <487a994c0812020028r22850e43l59522955c3c17d39@mail.gmail.com> Date: Tue, 2 Dec 2008 09:28:17 +0100 From: "Karl Pauls" To: dev@felix.apache.org Subject: Re: [jira] Commented: (FELIX-827) URLHandlers does not restore the previous URLStreamHandlerFactory after stopping Felix In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1866063768.1227142905035.JavaMail.jira@brutus> <785000022.1228178504224.JavaMail.jira@brutus> X-Virus-Checked: Checked by ClamAV on apache.org > 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) 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