[
https://issues.apache.org/jira/browse/SOLR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543693
]
Hoss Man commented on SOLR-409:
-------------------------------
as i mentioned on the mailing list a while back, it's not clear to me how
multicore stuff is expected to be used by people in the solr webapp (still
hoping to see some use cases / hypothetical-howtos on the wiki) but based on
the description/comments in this issue it seems that there are two ways a
libDir can be shared...
1) by specifying a libDir in some file i've never seen before called
"multicore.xml"
2) by declaring it shared in the solrconfig.xml files of 2 or more cores
#1 makes sense to me ... the correct thing to do seems to be to let whatever
new object exists to manage cores (CoreManager?) have it's own ClassLoader that
is used when initializing cores (this will then become the parent loader for
the class loaders created by each core) ... this "multicore parent classloader"
would be configured in the CoreManager's config file (multicore.xml?)
#2 seems scary ... particularly because it allows "sister" cores, initialized
by the same classloader to share instances of a class that their own
classloader doesn't know about. there's also the issues of how things should
behave if two different cores refer to the same physical jar/classfile but do
so using different paths (which might be symlinks or hardlinks and won't even
have the same canonical path); as well as the question of what happens when we
dynamically "unload/reload all of the cores that were sharing a lib --
depending on the order of events, and garbage collection, classes might be
completely reloaded (or not)
let's keep the classloader semantics simple, and hierarchical:
1) every core has a plugin classloader.
2) every plugin classloader has a common parent classloader
3) the common parent classloader may contain shared libraries
> 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.
