[
https://issues.apache.org/jira/browse/LUCENE-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler resolved LUCENE-2260.
-----------------------------------
Resolution: Fixed
Committed trunk revision: 909360
Committed 2.9 revision: 909361
Committed 3.0 revision: 909365
> 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-lucene29.patch, LUCENE-2260.patch,
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
