[ https://issues.apache.org/jira/browse/SOLR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henri Biestro updated SOLR-409: ------------------------------- Attachment: solr-350_409.patch cleaned up, less noisy version on trunk 601457; updated syntax for shared dir in multicore config; > 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-350_409.patch, solr-350_409_414.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.