lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Biestro (JIRA)" <>
Subject [jira] Updated: (SOLR-409) Allow configurable class loader sharing between cores
Date Wed, 05 Dec 2007 18:27:43 GMT


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:
>             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
> 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
> 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
> HOW:
> The libDir element is extracted from the XML configuration file and parsed in the Config
> 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.
> initial code drop

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message