Return-Path: X-Original-To: apmail-commons-issues-archive@minotaur.apache.org Delivered-To: apmail-commons-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 920B211695 for ; Tue, 22 Apr 2014 15:10:20 +0000 (UTC) Received: (qmail 90660 invoked by uid 500); 22 Apr 2014 15:10:15 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 90552 invoked by uid 500); 22 Apr 2014 15:10:15 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 90541 invoked by uid 99); 22 Apr 2014 15:10:15 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Apr 2014 15:10:15 +0000 Date: Tue, 22 Apr 2014 15:10:14 +0000 (UTC) From: "Ryan Boettcher (JIRA)" To: issues@commons.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (VFS-309) ThreadLocal memory leak in DefaultFileContent MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/VFS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976849#comment-13976849 ] Ryan Boettcher edited comment on VFS-309 at 4/22/14 3:08 PM: ------------------------------------------------------------- I tracked down a problem we were having that appears to be this bug. Turns out the ThreadLocal class can put more than one value it it's map if the same object in the same thread adds a value more than once. What should fix this is in the close() method instead of calling: threadData.set(null); the line should instead look like this: threadData.remove(); The set(null) method will either set the "exact" key matching value to null, or add a new entry, leaving all other map entries for the owning Object instance in the Thread until the thread ends. The remove() method attempts to remove all the entries for the instance, not just the exact match, though I admit I don't (atm) entirely understand how it does that. was (Author: golion): I tracked down a problem we were having that appears to be this bug. Turns out the ThreadLocal class can put more than one value it it's map if the same object in the same thread adds a value more than once. What should fix this is in the close() method instead of calling: threadData.set(null); the line should instead look like this: threadData.remove(); The set(value) method will either set the "exact" key matching value to null, or add a new entry, leaving all other map entries for the owning Object instance in the Thread until the thread ends. The remove() method attempts to remove all the entries for the instance, not just the exact match, though I admit I don't (atm) entirely understand how it does that. > ThreadLocal memory leak in DefaultFileContent > --------------------------------------------- > > Key: VFS-309 > URL: https://issues.apache.org/jira/browse/VFS-309 > Project: Commons VFS > Issue Type: Bug > Affects Versions: 2.0 > Environment: Tomcat servlet container > Reporter: jontro > > When using commons vfs in a servlet container the ThreadLocal values stored will not be released once the request finishes. > There needs to be a method to clear these values otherwise the data will leak into the next request. > This was detected with tomcat 6.0.26. Upon undeploying an app that uses commons vfs tomcat detects the leaks with a huge amount of the following messages: > A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@52fb241d]) and a value of type [org.apache.commons.vfs.provider.FileContentThreadData] (value [org.apache.commons.vfs.provider.FileContentThreadData@6600167a]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. -- This message was sent by Atlassian JIRA (v6.2#6252)