[
https://issues.apache.org/jira/browse/SOLR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543970
]
Hoss Man commented on SOLR-409:
-------------------------------
i'm not sure how to interpret "Yes #1, not #2" ... are you saying my
understanding about case #2 is wrong, or that you agree with me we shouldn't do
it? (i was basing that comment on the original issue description)
>> I don't see a need to have 'hierarchical' classloaders - a single global
>> shared library should be sufficient:
by hierarchical i'm referring to the normal way java classloaders work: every
classloader has a parent, which it delegates to automaticly. if we're going to
have a shared class loader available for all cores, then it should be the
parent of each core specific plugin classloader.
(currently the plugin ClassLoader uses the context classloader as it's parent
... that can still work as long as whatever "MultiCoreManager" object that
deals with multicore.xml uses the new "shared code classloader" as the context
when instantiating each SolrCore ... or we can be more explicit about it.)
> Allow configurable class loader sharing between cores
> -----------------------------------------------------
>
> Key: SOLR-409
> URL: https://issues.apache.org/jira/browse/SOLR-409
> Project: Solr
> Issue Type: Sub-task
> Affects Versions: 1.3
> Reporter: Henri Biestro
> Priority: Minor
> Fix For: 1.3
>
> Attachments: solr-350_409.patch, solr-350_409.patch,
> solr-350_409.patch, solr-409.patch, solr-409.patch
>
>
> WHAT:
> This patch allows to configure in the solrconfig.xml the library directory
> and associated class loader used to dynamically create instances.
> The solr config XML can now specify a libDir element (the same way the
> dataDir can be specified).
> That element can also specify through the 'shared' attribute whether the
> library is shared.
> By default, the shared attribute is true; if you specify a libDir, its class
> loader is made shareable.
> Syntax:
> <libDir shared='true*|false'>/path/to/shareable/dir</libDir>
> WHY:
> Current behavior allocates one class loader per config & thus per core.
> However, there are cases where one would like different cores to share some
> objects that are dynamically instantiated (ie, where the class name is used
> to find the class through the class loader and instantiate). In the current
> form; since each core possesses its own class loader, static members are
> indeed different objects. For instance, there is no way of implementing a
> singleton shared between 2 request handlers.
> Originally from
> http://www.nabble.com/Post-SOLR215-SOLR350-singleton-issue-tf4776980.html
> HOW:
> The libDir element is extracted from the XML configuration file and parsed in
> the Config constructor.
> A static map of weak reference to classloaders keyed by library path is used
> to keep track of already built shareable class loaders.
> The weak reference is here to allow class eviction by the GC, avoiding
> leakage that would result by keeping hard reference to class loaders.
> STATUS:
> initial code drop
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
