[
https://issues.apache.org/jira/browse/SOLR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542562
]
Walter Ferrara commented on SOLR-409:
-------------------------------------
I ran some test, it seems to work really fine.
I like the way you choose to show admin pages for each cores.
I noticed that when I click on "SCHEMA" I get:
<ERROR>
Permission denied for file solr\core0//conf/schema.xml
</ERROR>
"SCHEMA" link point to
http://localhost:8983/solr/admin/get-file.jsp?core=core0&file=solr\core0//conf/schema.xml
Interesting "CONFIG" links works fine
(http://localhost:8983/solr/admin/get-file.jsp?core=core0&file=solrconfig.xml)
taking a look at index.jsp in admin seems that core.getSchemaFile() add paths,
while core.getConfigFile() don't.
I had an idea:
Solr currently log info to the "console", this info have no track of which core
executed the action, e.g.
14-nov-2007 20.33.51 org.apache.solr.core.SolrCore execute
INFO: /select/ indent=on&start=0&q=solr&version=2.2&rows=10 0 0
14-nov-2007 20.33.54 org.apache.solr.core.SolrCore execute
INFO: /select/ indent=on&start=0&q=solr&version=2.2&rows=10 0 0
The first one was executed on "core0", while the latter on "core1" - no way to
determine it from those log lines.
I was wondering, what are your thoughts about putting core name somewhere in
logging info, ie.
14-nov-2007 20.33.51 org.apache.solr.core.SolrCore execute
INFO: [core0] /select/ indent=on&start=0&q=solr&version=2.2&rows=10 0 0
14-nov-2007 20.33.54 org.apache.solr.core.SolrCore execute
INFO: [core1] /select/ indent=on&start=0&q=solr&version=2.2&rows=10 0 0
--
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-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.
