lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LUCENE-2260) AttributeSource holds strong reference to class instances and prevents unloading e.g. in Solr if webapplication reload and custom attributes in separate classloaders are used (e.g. in the Solr plugins classloader)
Date Thu, 11 Feb 2010 13:32:28 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Uwe Schindler updated LUCENE-2260:
----------------------------------

    Attachment: LUCENE-2260.patch

Attached patch. I will commit this in a day and also merge to 2.9 and 3.0 (without VirtualMethod)
as this is a resource leak. This problem is similar to LUCENE-2182.

> AttributeSource holds strong reference to class instances and prevents unloading e.g.
in Solr if webapplication reload and custom attributes in separate classloaders are used (e.g.
in the Solr plugins classloader)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2260
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2260
>             Project: Lucene - Java
>          Issue Type: Bug
>    Affects Versions: 2.9.1, 3.0
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 2.9.2, 3.0.1, 3.1
>
>         Attachments: LUCENE-2260.patch
>
>
> When working on the dynmaic proxy classes using cglib/javaassist i recognized a problem
in the caching code inside AttributeSource:
> - AttributeSource has a static (!) cache map that holds implementation classes for attributes
to be faster on creating new attributes (reflection cost)
> - AttributeSource has a static (!) cache map that holds a list of all interfaces implemented
by a specific AttributeImpl
> Also:
> - VirtualMethod in 3.1 hold a map of implementation distances keyed by subclasses of
the deprecated API
> Both have the problem that this strong reference is inside Lucene's classloader and so
persists as long as lucene lives. The classes referenced can never be unloaded therefore,
which would be fine if all live in the same classloader. As soon as the Attribute or implementation
class or the subclass of the deprecated API are loaded by a different classloder (e.g. Lucene
lives in bootclasspath of tomcat, but lucene-consumer with custom attributes lives in a webapp),
they can never be unloaded, because a reference exists.
> Libs like CGLIB or JavaAssist or JDK's reflect.Proxy have a similar cache for generated
class files. They also manage this by a WeakHashMap. The cache will always work perfect and
no class will be evicted without reason, as classes are only unloaded when the classloader
goes and this will only happen on request (e.g. by Tomcat).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message