[jira] Commented: (SOLR-409) Allow configurable class loader sharing between cores

["Walter Ferrara (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541762 ] 

Walter Ferrara commented on SOLR-409:
-------------------------------------

Thanks very much!
a) In order to apply the patch, I've locally modified it to look for Config.java in src/java/org/apache/solr/core/Config.java
b) Don't seems to work with SOLR-350. (I understand it just depends on solr-215, which is in trunk, but what about SOLR-350? It could be interesting to apply it over solr-350, for a future join maybe)

If I apply solr-409.patch before SOLR-350-MultiCore.patch, the 409 goes well and 350 produce errors, otherwise the 350 goes well, and then:
patching file src/java/org/apache/solr/core/Config.java
Hunk #2 FAILED at 54.
Hunk #3 succeeded at 91 (offset 1 line).
Hunk #4 succeeded at 178 (offset 1 line).
Hunk #5 succeeded at 344 (offset 10 lines).
Hunk #6 succeeded at 364 (offset 10 lines).
Hunk #7 succeeded at 405 (offset 10 lines).
Hunk #8 succeeded at 424 (offset 10 lines).
1 out of 8 hunks FAILED -- saving rejects to file src/java/org/apache/solr/core/Config.java.rej

ALSO:

We should choose where is the best place to put the info about the shared lib dir. 
In this patch I can choose if to share or not to share, which is ok for me, but an user could be so lazy that wants to share just something, not every jars of his core :-) 
Another approach could be to use SOLR-350 and put the info about the share directory info in multicore.xml, like:

<multicore enabled="true" adminpath="/admin/multicore" persistent="true" sharedLibDir="lib">
 <core name="core0" instanceDir="core0" default="true"/>
 <core name="core1" instanceDir="core1" />
</multicore>

Where sharedLibDir indicate where to locate shared libraries - this way it could be the same of a core, but it could be a totally different one too.
Any thoughts?
--
Walter

> 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-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.