[jira] Commented: (SOLR-1167) Support module xml config files using XInclude
[
https://issues.apache.org/jira/browse/SOLR-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753840#action_12753840
]
Henri Biestro commented on SOLR-1167:
-
Just a thought; wouldn'it be possible to use system entities (as in SOLR-712 /
SOLR-646) to have variables resolution in entities and use those in the
xi:include href ?
{code}
]>
...
...
{code}
This would allow include of files using variables using standards without
reverting the inclusion logic.
In any case, thanks Bryan for pushing this.
> Support module xml config files using XInclude
> --
>
> Key: SOLR-1167
> URL: https://issues.apache.org/jira/browse/SOLR-1167
> Project: Solr
> Issue Type: New Feature
>Reporter: Bryan Talbot
>Priority: Minor
> Attachments: SOLR-1167.patch, SOLR-1167.patch, SOLR-1167.patch
>
>
> Current configuration files (schema and solrconfig) are monolithic which can
> make maintenance and reuse more difficult that it needs to be. The XML
> standards include a feature to include content from external files. This is
> described at http://www.w3.org/TR/xinclude/
> This feature is to add support for XInclude features for XML configuration
> files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1154) allow specifying solr configuration file through system property to simplify deployment procedure in certain cases
[
https://issues.apache.org/jira/browse/SOLR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12709483#action_12709483
]
Henri Biestro commented on SOLR-1154:
-
{quote}
BTW the root of the problem is that there is no way to include snippets of
configuration from external files . I guess that needs to be addressed
separately
{quote}
Do you mean the "include" features in SOLR-646 ?
> allow specifying solr configuration file through system property to simplify
> deployment procedure in certain cases
> --
>
> Key: SOLR-1154
> URL: https://issues.apache.org/jira/browse/SOLR-1154
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jianhan
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1154.patch, SOLR-1154.patch
>
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> Hi,
> I wanted to use this parameter to specify different solr configuration files
> for master and slave to simplify deployment procedure. Unfortunately, I can't
> dynamically replace the value of this parameter. Basically, what I want is
>
> SolrRequestFilter
> org.apache.solr.servlet.SolrDispatchFilter
>
> solrconfig-filename
> solrconfig-master.xml
>
>
> for master instance, and
>
> SolrRequestFilter
> org.apache.solr.servlet.SolrDispatchFilter
>
> solrconfig-filename
> solrconfig-slave.xml
>
>
> for slave instance.
> Ideally, if I can use system property for its value like in solrconfig.xml.
> For example,
>
> SolrRequestFilter
> org.apache.solr.servlet.SolrDispatchFilter
>
> solrconfig-filename
> ${solr.config.filename: solrconfig.xml}
>
>
> but I learned that in general we can't use system property in web.xml.
> I realize that I can use replication of config file to achieve this, but I
> thought that creates unnecessary dependencies for slaves on master instance.
> So here is my proposal:
> make SolrDispatchFilter look up another init parameter, say
> 'solrconfig-filename-property', and its value is a system property name, and
> if this property is set, we get the file name, otherwise nothing happens (of
> course, if both exist, 'solrconfig-filename' takes precedence). This will
> give us maximum flexibility of specifying configuration files for different
> instances.
> Your thoughts?
> Thanks,
> Jianhan
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-725: --- Fix Version/s: (was: 1.3.1) 1.4 > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Fix For: 1.4 > > Attachments: solr-725.patch, solr-725.patch, solr-725.patch, > solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *rename*: renames a core > h3. CoreAdminHandler: handles CoreContainer operations > * *load*/*create*: CoreContainer load > * *unload*: CoreContainer unload > * *reload*: CoreContainer reload > * *swap*: CoreContainer swap > * *alias*: CoreContainer alias > * *unalias*: CoreContainer unalias > * *rename*: CoreContainer rename > * *persist*: CoreContainer persist, writes the solr.xml > **stauts*: returns the status of all/one SolrCore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-731) CoreDescriptor.getCoreContainer should not be public
[ https://issues.apache.org/jira/browse/SOLR-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-731: --- Fix Version/s: (was: 1.3.1) 1.4 > CoreDescriptor.getCoreContainer should not be public > > > Key: SOLR-731 > URL: https://issues.apache.org/jira/browse/SOLR-731 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Henri Biestro > Fix For: 1.4 > > Attachments: solr-731.patch > > > For the very same reasons that CoreDescriptor.getCoreProperties did not need > to be public (aka SOLR-724) > It also means the CoreDescriptor ctor should not need a CoreContainer > The CoreDescriptor is only meant to be describing a "to-be created SolrCore". > However, we need access to the CoreContainer from the SolrCore now that we > are guaranteed the CoreContainer always exists. > This is also a natural consequence of SOLR-647 now that the CoreContainer is > not a map of CoreDescriptor but a map of SolrCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-735) CoreContainer.unload should remove all aliases of a core
[ https://issues.apache.org/jira/browse/SOLR-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-735: --- Fix Version/s: (was: 1.3.1) 1.4 > CoreContainer.unload should remove all aliases of a core > > > Key: SOLR-735 > URL: https://issues.apache.org/jira/browse/SOLR-735 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Henri Biestro > Fix For: 1.4 > > > Similar to SOLR-722, this is a *core* operation (like load/reload); it should > affect all aliases of a core. > In this case, it should close the core through all its aliases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-725: --- Attachment: solr-725.patch updated for trunk 720487 > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Fix For: 1.3.1 > > Attachments: solr-725.patch, solr-725.patch, solr-725.patch, > solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *rename*: renames a core > h3. CoreAdminHandler: handles CoreContainer operations > * *load*/*create*: CoreContainer load > * *unload*: CoreContainer unload > * *reload*: CoreContainer reload > * *swap*: CoreContainer swap > * *alias*: CoreContainer alias > * *unalias*: CoreContainer unalias > * *rename*: CoreContainer rename > * *persist*: CoreContainer persist, writes the solr.xml > **stauts*: returns the status of all/one SolrCore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-731) CoreDescriptor.getCoreContainer should not be public
[ https://issues.apache.org/jira/browse/SOLR-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-731: --- Fix Version/s: 1.3.1 > CoreDescriptor.getCoreContainer should not be public > > > Key: SOLR-731 > URL: https://issues.apache.org/jira/browse/SOLR-731 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Henri Biestro > Fix For: 1.3.1 > > Attachments: solr-731.patch > > > For the very same reasons that CoreDescriptor.getCoreProperties did not need > to be public (aka SOLR-724) > It also means the CoreDescriptor ctor should not need a CoreContainer > The CoreDescriptor is only meant to be describing a "to-be created SolrCore". > However, we need access to the CoreContainer from the SolrCore now that we > are guaranteed the CoreContainer always exists. > This is also a natural consequence of SOLR-647 now that the CoreContainer is > not a map of CoreDescriptor but a map of SolrCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-735) CoreContainer.unload should remove all aliases of a core
[ https://issues.apache.org/jira/browse/SOLR-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-735: --- Fix Version/s: 1.3.1 > CoreContainer.unload should remove all aliases of a core > > > Key: SOLR-735 > URL: https://issues.apache.org/jira/browse/SOLR-735 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Henri Biestro > Fix For: 1.3.1 > > > Similar to SOLR-722, this is a *core* operation (like load/reload); it should > affect all aliases of a core. > In this case, it should close the core through all its aliases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-725: --- Fix Version/s: 1.3.1 > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Fix For: 1.3.1 > > Attachments: solr-725.patch, solr-725.patch, solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *rename*: renames a core > h3. CoreAdminHandler: handles CoreContainer operations > * *load*/*create*: CoreContainer load > * *unload*: CoreContainer unload > * *reload*: CoreContainer reload > * *swap*: CoreContainer swap > * *alias*: CoreContainer alias > * *unalias*: CoreContainer unalias > * *rename*: CoreContainer rename > * *persist*: CoreContainer persist, writes the solr.xml > **stauts*: returns the status of all/one SolrCore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-745) CoreAdminHandler in bad state after UNLOADing core
[
https://issues.apache.org/jira/browse/SOLR-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627610#action_12627610
]
henrib edited comment on SOLR-745 at 9/2/08 2:04 AM:
You are correct, refcounting on cores was introduced in SOLR-647. Before this,
it was possible to close a core whilst it was serving requests.
The admin core is "any" core that is used so admin requests can be served
(request handling assumes a core exists); it is kept around through a weak
reference to avoid looking for a new one each time an admin request is handled
and is only maintained "opened" during execution of the request (like any other
request wrt refcounting for that matter; incref - aka open - when we acquire
the core, execute the query, decref - aka close - as release).
The side effect is that the reference can point to a core that is closed but
not yet GC-ed thus the bug & the fix.
As a side note, the java.util.concurrent.RejectedExecutionException is the
typical symptom when trying to execute a query on a closed core.
was (Author: henrib):
You are correct, refcounting on cores was introduced in SOLR-647. Before
this, it was possible to close a core whilst it was serving requests.
The admin core is "any" core that is used so admin requests can be served
(request handling assumes a core exists); it is kept around through a weak
reference to avoid looking for a new one each time an admin request is handled
and is only maintained "opened" during execution of the request (like any other
request wrt refcounting for that matter; incref -aka open- when we acquire the
core, execute the query, decref -aka close- as release).
The side effect is that the reference can point to a core that is closed but
not yet GC-ed thus the bug & the fix.
As a side note, the java.util.concurrent.RejectedExecutionException is the
typical symptom when trying to execute a query on a closed core.
> CoreAdminHandler in bad state after UNLOADing core
> --
>
> Key: SOLR-745
> URL: https://issues.apache.org/jira/browse/SOLR-745
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: solr-745.patch
>
>
> using 1.3-rc1...
> # Start up the multicore example...{noformat}
> cd example
> java -Dsolr.solr.home=multicore -jar start.jar
> {noformat}
> # Hit the status URL repeatedly:
> http://localhost:8983/solr/admin/cores?action=STATUS
> # Note: no problems in the log
> # unload core0:
> http://localhost:8983/solr/admin/cores?action=UNLOAD&core=core0
> # shift-reload on the status URL:
> http://localhost:8983/solr/admin/cores?action=STATUS
> # Note the following exception each time...{noformat}
> SEVERE: java.util.concurrent.RejectedExecutionException
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:606)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1062)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:821)
> at
> org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:208)
> at
> org.apache.solr.servlet.cache.HttpCacheHeaderUtil.calcLastModified(HttpCacheHeaderUtil.java:146)
> at
> org.apache.solr.servlet.cache.HttpCacheHeaderUtil.doCacheHeaderValidation(HttpCacheHeaderUtil.java:220)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:224)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
> at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.
[jira] Commented: (SOLR-745) CoreAdminHandler in bad state after UNLOADing core
[
https://issues.apache.org/jira/browse/SOLR-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627610#action_12627610
]
Henri Biestro commented on SOLR-745:
You are correct, refcounting on cores was introduced in SOLR-647. Before this,
it was possible to close a core whilst it was serving requests.
The admin core is "any" core that is used so admin requests can be served
(request handling assumes a core exists); it is kept around through a weak
reference to avoid looking for a new one each time an admin request is handled
and is only maintained "opened" during execution of the request (like any other
request wrt refcounting for that matter; incref -aka open- when we acquire the
core, execute the query, decref -aka close- as release).
The side effect is that the reference can point to a core that is closed but
not yet GC-ed thus the bug & the fix.
As a side note, the java.util.concurrent.RejectedExecutionException is the
typical symptom when trying to execute a query on a closed core.
> CoreAdminHandler in bad state after UNLOADing core
> --
>
> Key: SOLR-745
> URL: https://issues.apache.org/jira/browse/SOLR-745
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: solr-745.patch
>
>
> using 1.3-rc1...
> # Start up the multicore example...{noformat}
> cd example
> java -Dsolr.solr.home=multicore -jar start.jar
> {noformat}
> # Hit the status URL repeatedly:
> http://localhost:8983/solr/admin/cores?action=STATUS
> # Note: no problems in the log
> # unload core0:
> http://localhost:8983/solr/admin/cores?action=UNLOAD&core=core0
> # shift-reload on the status URL:
> http://localhost:8983/solr/admin/cores?action=STATUS
> # Note the following exception each time...{noformat}
> SEVERE: java.util.concurrent.RejectedExecutionException
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:606)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1062)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:821)
> at
> org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:208)
> at
> org.apache.solr.servlet.cache.HttpCacheHeaderUtil.calcLastModified(HttpCacheHeaderUtil.java:146)
> at
> org.apache.solr.servlet.cache.HttpCacheHeaderUtil.doCacheHeaderValidation(HttpCacheHeaderUtil.java:220)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:224)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
> at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
> at
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> {noformat}
> # Note that the exception doesn't just happen the first time you reload the
> status URL, but everytime.
> Marking "Fix in 1.3" until someone smarter then me about CoreAdminHandler
> says it's no big deal.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online
[jira] Issue Comment Edited: (SOLR-745) CoreAdminHandler in bad state after UNLOADing core
[
https://issues.apache.org/jira/browse/SOLR-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627502#action_12627502
]
henrib edited comment on SOLR-745 at 9/1/08 3:21 PM:
The uploaded patch fixes it (Linux/Ubuntu 8.04/Java 1.6)
was (Author: henrib):
Seems like this fixes it.
> CoreAdminHandler in bad state after UNLOADing core
> --
>
> Key: SOLR-745
> URL: https://issues.apache.org/jira/browse/SOLR-745
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: solr-745.patch
>
>
> using 1.3-rc1...
> # Start up the multicore example...{noformat}
> cd example
> java -Dsolr.solr.home=multicore -jar start.jar
> {noformat}
> # Hit the status URL repeatedly:
> http://localhost:8983/solr/admin/cores?action=STATUS
> # Note: no problems in the log
> # unload core0:
> http://localhost:8983/solr/admin/cores?action=UNLOAD&core=core0
> # shift-reload on the status URL:
> http://localhost:8983/solr/admin/cores?action=STATUS
> # Note the following exception each time...{noformat}
> SEVERE: java.util.concurrent.RejectedExecutionException
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:606)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1062)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:821)
> at
> org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:208)
> at
> org.apache.solr.servlet.cache.HttpCacheHeaderUtil.calcLastModified(HttpCacheHeaderUtil.java:146)
> at
> org.apache.solr.servlet.cache.HttpCacheHeaderUtil.doCacheHeaderValidation(HttpCacheHeaderUtil.java:220)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:224)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
> at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
> at
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> {noformat}
> # Note that the exception doesn't just happen the first time you reload the
> status URL, but everytime.
> Marking "Fix in 1.3" until someone smarter then me about CoreAdminHandler
> says it's no big deal.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-745) CoreAdminHandler in bad state after UNLOADing core
[
https://issues.apache.org/jira/browse/SOLR-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-745:
---
Attachment: solr-745.patch
Seems like this fixes it.
> CoreAdminHandler in bad state after UNLOADing core
> --
>
> Key: SOLR-745
> URL: https://issues.apache.org/jira/browse/SOLR-745
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: solr-745.patch
>
>
> using 1.3-rc1...
> # Start up the multicore example...{noformat}
> cd example
> java -Dsolr.solr.home=multicore -jar start.jar
> {noformat}
> # Hit the status URL repeatedly:
> http://localhost:8983/solr/admin/cores?action=STATUS
> # Note: no problems in the log
> # unload core0:
> http://localhost:8983/solr/admin/cores?action=UNLOAD&core=core0
> # shift-reload on the status URL:
> http://localhost:8983/solr/admin/cores?action=STATUS
> # Note the following exception each time...{noformat}
> SEVERE: java.util.concurrent.RejectedExecutionException
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:606)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1062)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:821)
> at
> org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:208)
> at
> org.apache.solr.servlet.cache.HttpCacheHeaderUtil.calcLastModified(HttpCacheHeaderUtil.java:146)
> at
> org.apache.solr.servlet.cache.HttpCacheHeaderUtil.doCacheHeaderValidation(HttpCacheHeaderUtil.java:220)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:224)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
> at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
> at
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> {noformat}
> # Note that the exception doesn't just happen the first time you reload the
> status URL, but everytime.
> Marking "Fix in 1.3" until someone smarter then me about CoreAdminHandler
> says it's no big deal.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-745) CoreAdminHandler in bad state after UNLOADing core
[
https://issues.apache.org/jira/browse/SOLR-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627419#action_12627419
]
henrib edited comment on SOLR-745 at 9/1/08 3:02 AM:
Part of it might be in 'CoreContainer.getAdminHandler()' which should check
that the (previous) admin core is not closed before attempting to (re)use it.
Adding a check for isClosed() seems necessary.
Something like:
{code}
public SolrCore getAdminCore() {
synchronized (cores) {
SolrCore core = adminCore != null ? adminCore.get() : null;
if (core != null && !core.isClosed()) {
core.open();
} else {
{code}
was (Author: henrib):
Part of it might be in 'getAdminHandler()' which should check that the
(previous) admin core is not closed before attempting to (re)use it.
Adding a check for isClosed() seems necessary.
Something like:
{code}
public SolrCore getAdminCore() {
synchronized (cores) {
SolrCore core = adminCore != null ? adminCore.get() : null;
if (core != null && !core.isClosed()) {
core.open();
} else {
{code}
> CoreAdminHandler in bad state after UNLOADing core
> --
>
> Key: SOLR-745
> URL: https://issues.apache.org/jira/browse/SOLR-745
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Hoss Man
> Fix For: 1.3
>
>
> using 1.3-rc1...
> # Start up the multicore example...{noformat}
> cd example
> java -Dsolr.solr.home=multicore -jar start.jar
> {noformat}
> # Hit the status URL repeatedly:
> http://localhost:8983/solr/admin/cores?action=STATUS
> # Note: no problems in the log
> # unload core0:
> http://localhost:8983/solr/admin/cores?action=UNLOAD&core=core0
> # shift-reload on the status URL:
> http://localhost:8983/solr/admin/cores?action=STATUS
> # Note the following exception each time...{noformat}
> SEVERE: java.util.concurrent.RejectedExecutionException
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:606)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1062)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:821)
> at
> org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:208)
> at
> org.apache.solr.servlet.cache.HttpCacheHeaderUtil.calcLastModified(HttpCacheHeaderUtil.java:146)
> at
> org.apache.solr.servlet.cache.HttpCacheHeaderUtil.doCacheHeaderValidation(HttpCacheHeaderUtil.java:220)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:224)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
> at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
> at
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> {noformat}
> # Note that the exception doesn't just happen the first time you reload the
> status URL, but everytime.
> Marking "Fix in 1.3" until someone smarter then me about CoreAdminHandler
> says it's no big deal.
--
This message is automatically generated by JIRA.
-
You c
[jira] Commented: (SOLR-745) CoreAdminHandler in bad state after UNLOADing core
[
https://issues.apache.org/jira/browse/SOLR-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627419#action_12627419
]
Henri Biestro commented on SOLR-745:
Part of it might be in 'getAdminHandler()' which should check that the
(previous) admin core is not closed before attempting to (re)use it.
Adding a check for isClosed() seems necessary.
Something like:
{code}
public SolrCore getAdminCore() {
synchronized (cores) {
SolrCore core = adminCore != null ? adminCore.get() : null;
if (core != null && !core.isClosed()) {
core.open();
} else {
{code}
> CoreAdminHandler in bad state after UNLOADing core
> --
>
> Key: SOLR-745
> URL: https://issues.apache.org/jira/browse/SOLR-745
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Hoss Man
> Fix For: 1.3
>
>
> using 1.3-rc1...
> # Start up the multicore example...{noformat}
> cd example
> java -Dsolr.solr.home=multicore -jar start.jar
> {noformat}
> # Hit the status URL repeatedly:
> http://localhost:8983/solr/admin/cores?action=STATUS
> # Note: no problems in the log
> # unload core0:
> http://localhost:8983/solr/admin/cores?action=UNLOAD&core=core0
> # shift-reload on the status URL:
> http://localhost:8983/solr/admin/cores?action=STATUS
> # Note the following exception each time...{noformat}
> SEVERE: java.util.concurrent.RejectedExecutionException
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:606)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1062)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:821)
> at
> org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:208)
> at
> org.apache.solr.servlet.cache.HttpCacheHeaderUtil.calcLastModified(HttpCacheHeaderUtil.java:146)
> at
> org.apache.solr.servlet.cache.HttpCacheHeaderUtil.doCacheHeaderValidation(HttpCacheHeaderUtil.java:220)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:224)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
> at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
> at
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> {noformat}
> # Note that the exception doesn't just happen the first time you reload the
> status URL, but everytime.
> Marking "Fix in 1.3" until someone smarter then me about CoreAdminHandler
> says it's no big deal.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-731) CoreDescriptor.getCoreContainer should not be public
[ https://issues.apache.org/jira/browse/SOLR-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627035#action_12627035 ] Henri Biestro commented on SOLR-731: The issue is about having public access from CD to the CC. I think that it would be misleading to other contributors to believe the CD is more than a parameter passing facility; it should not be used beyond core creation. Removing the SC->CD reference altogether is a strawman feature (at least, I know why this code should not not make it to the trunk). But it illustrates the point that this reference is not functionally needed since all information vehicled though the CD is exploited then stored elsewhere. As you mentioned, CoreDescriptor/CoreContainer/SolrCore are intertwined so it is hard to cut those in pieces as I've been asked to do. For all intent & purpose, SOLR-725 related issues are resolved in the SOLR-725 attached patch. > CoreDescriptor.getCoreContainer should not be public > > > Key: SOLR-731 > URL: https://issues.apache.org/jira/browse/SOLR-731 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-731.patch > > > For the very same reasons that CoreDescriptor.getCoreProperties did not need > to be public (aka SOLR-724) > It also means the CoreDescriptor ctor should not need a CoreContainer > The CoreDescriptor is only meant to be describing a "to-be created SolrCore". > However, we need access to the CoreContainer from the SolrCore now that we > are guaranteed the CoreContainer always exists. > This is also a natural consequence of SOLR-647 now that the CoreContainer is > not a map of CoreDescriptor but a map of SolrCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626993#action_12626993 ] Henri Biestro commented on SOLR-725: Paul Would it be fair to say that you fear the alias/hardlink feature would allow users to make configuration/manipulation mistakes more easily wrt replication? As is, it does not remove any feature nor forces anyone into using them; thus, it's not breaking anything nor does it make your use-cases more difficult. It might be used in a wrong way and I'm not arguing that since it creates possibility and more choices, it can lead to more mistakes. And in that sense, some users could end up not being able to use the feature you contribute. I do believe though that it's better to describe & educate on best practices than constrain usage. I also understand that for solr-727/solr-561, you need some URLs to be stable (which is what the "cool uris dont change" motto advocates and this is a good rule). Allowing more ways to alias a core is an easier path (no pun intended) to this than constraining users into having just one. I can even dedicate a URL to replication that is not something my end-users would ever need to know (since I dont think my deployment constraints or choices should reflect into what they use). Aliasing (the hardlink model) is not adverse to replication usage conventions & needs, it instead does allow to respect them more easily with more flexibility. Just a different Solr user & contributor opinion. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch, solr-725.patch, solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *rename*: renames a core > h3. CoreAdminHandler: handles CoreContainer operations > * *load*/*create*: CoreContainer load > * *unload*: CoreContainer unload > * *reload*: CoreContainer reload > * *swap*: CoreContainer swap > * *alias*: CoreContainer alias > * *unalias*: CoreContainer unalias > * *rename*: CoreContainer rename > * *persist*: CoreContainer persist, writes the solr.xml > **stauts*: returns the status of all/one SolrCore -- This message is automatically generated by JIRA. - You can repl
[jira] Updated: (SOLR-736) SolrCore.getSolrCore() may create a SolrCore without a CoreContainer
[
https://issues.apache.org/jira/browse/SOLR-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-736:
---
Description:
The method is deprecated but one can still initialize & start working this way.
Potential fix could be:
{code}
@Deprecated
public static SolrCore getSolrCore() {
synchronized( SolrCore.class ) {
if( instance == null ) {
try {
// sets 'instance' to the latest solr core
CoreContainer.Initializer init = new CoreContainer.Initializer();
instance = init.initialize().getCore("");
} catch(Exception xany) {
throw new SolrException( SolrException.ErrorCode.SERVER_ERROR,
"error creating core", xany );
}
}
}
return instance;
}
{code}
was:
The method is deprecated but one can still initialize & start working this way.
Potential fix could be:
{code}
@Deprecated
public static SolrCore getSolrCore() {
synchronized( SolrCore.class ) {
if( instance == null ) {
try {
// sets 'instance' to the latest solr core
final SolrConfig solrConfig = new SolrConfig();
final IndexSchema indexSchema = new IndexSchema(solrConfig,
"schema.xml", null);
CoreContainer.Initializer init = new CoreContainer.Initializer() {
@Override
public CoreContainer initialize() {
CoreContainer container = new CoreContainer(new
SolrResourceLoader(SolrResourceLoader.locateInstanceDir()));
CoreDescriptor dcore = new CoreDescriptor("",
solrConfig.getResourceLoader().getInstanceDir());
dcore.setCoreContainer(container);
dcore.setConfigName(solrConfig.getResourceName());
dcore.setSchemaName(indexSchema.getResourceName());
SolrCore core = new SolrCore(null, null, solrConfig, indexSchema,
dcore);
container.register(null, core, false);
return container;
}
};
instance = init.initialize().getCore("");
} catch(Exception xany) {
throw new SolrException( SolrException.ErrorCode.SERVER_ERROR,
"error creating core", xany );
}
}
}
return instance;
}
{code}
> SolrCore.getSolrCore() may create a SolrCore without a CoreContainer
>
>
> Key: SOLR-736
> URL: https://issues.apache.org/jira/browse/SOLR-736
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>
> The method is deprecated but one can still initialize & start working this
> way.
> Potential fix could be:
> {code}
> @Deprecated
> public static SolrCore getSolrCore() {
> synchronized( SolrCore.class ) {
> if( instance == null ) {
> try {
> // sets 'instance' to the latest solr core
> CoreContainer.Initializer init = new CoreContainer.Initializer();
> instance = init.initialize().getCore("");
> } catch(Exception xany) {
> throw new SolrException( SolrException.ErrorCode.SERVER_ERROR,
> "error creating core", xany );
> }
> }
> }
> return instance;
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-736) SolrCore.getSolrCore() may create a SolrCore without a CoreContainer
SolrCore.getSolrCore() may create a SolrCore without a CoreContainer
Key: SOLR-736
URL: https://issues.apache.org/jira/browse/SOLR-736
Project: Solr
Issue Type: Bug
Affects Versions: 1.3
Reporter: Henri Biestro
The method is deprecated but one can still initialize & start working this way.
Potential fix could be:
{code}
@Deprecated
public static SolrCore getSolrCore() {
synchronized( SolrCore.class ) {
if( instance == null ) {
try {
// sets 'instance' to the latest solr core
final SolrConfig solrConfig = new SolrConfig();
final IndexSchema indexSchema = new IndexSchema(solrConfig,
"schema.xml", null);
CoreContainer.Initializer init = new CoreContainer.Initializer() {
@Override
public CoreContainer initialize() {
CoreContainer container = new CoreContainer(new
SolrResourceLoader(SolrResourceLoader.locateInstanceDir()));
CoreDescriptor dcore = new CoreDescriptor("",
solrConfig.getResourceLoader().getInstanceDir());
dcore.setCoreContainer(container);
dcore.setConfigName(solrConfig.getResourceName());
dcore.setSchemaName(indexSchema.getResourceName());
SolrCore core = new SolrCore(null, null, solrConfig, indexSchema,
dcore);
container.register(null, core, false);
return container;
}
};
instance = init.initialize().getCore("");
} catch(Exception xany) {
throw new SolrException( SolrException.ErrorCode.SERVER_ERROR,
"error creating core", xany );
}
}
}
return instance;
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-734) NPE in SolrCore
[ https://issues.apache.org/jira/browse/SOLR-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626540#action_12626540 ] Henri Biestro commented on SOLR-734: Seen the thread as http://www.nabble.com/CoreDescriptor-explanation-and-possible-bug-to19197004.html Hava a look at the org.apache.solr.util.TestHarness initializer , that should be close to it. > NPE in SolrCore > --- > > Key: SOLR-734 > URL: https://issues.apache.org/jira/browse/SOLR-734 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Nikhil Chhaochharia > Fix For: 1.3 > > > SolrCore.getStatistics() calls > getCoreDescriptor().getCoreContainer().getCoreNames(this) without checking if > the CoreDescriptor is null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-735) CoreContainer.unload should remove all aliases of a core
CoreContainer.unload should remove all aliases of a core Key: SOLR-735 URL: https://issues.apache.org/jira/browse/SOLR-735 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Henri Biestro Similar to SOLR-722, this is a *core* operation (like load/reload); it should affect all aliases of a core. In this case, it should close the core through all its aliases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626522#action_12626522 ] henrib edited comment on SOLR-725 at 8/28/08 4:30 AM: - added remaining operations and their mappings in CoreAdminRequest; added specific tests to check refCount / number of aliases are kept in sync; minor modifications so calling close is usually performed outside of the synchronized block on cores (to reduce contention). change: unloadCore is now a *core* operation, it unloads the core (removes all its aliases thus really closes/unloads the core); unaliasCore is an *alias* operation and only removes the alias. was (Author: henrib): added remaining operations and their mappings in CoreAdminRequest; added specific tests to check refCount / number of aliases are kept in sync; change: unloadCore is now a *core* operation, it unloads the core (removes all its aliases thus really closes/unloads the core); unaliasCore is an *alias* operation and only removes the alias. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch, solr-725.patch, solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *rename*: renames a core > h3. CoreAdminHandler: handles CoreContainer operations > * *load*/*create*: CoreContainer load > * *unload*: CoreContainer unload > * *reload*: CoreContainer reload > * *swap*: CoreContainer swap > * *alias*: CoreContainer alias > * *unalias*: CoreContainer unalias > * *rename*: CoreContainer rename > * *persist*: CoreContainer persist, writes the solr.xml > **stauts*: returns the status of all/one SolrCore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-725: --- Attachment: solr-725.patch added remaining operations and their mappings in CoreAdminRequest; added specific tests to check refCount / number of aliases are kept in sync; change: unloadCore is now a *core* operation, it unloads the core (removes all its aliases thus really closes/unloads the core); unaliasCore is an *alias* operation and only removes the alias. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch, solr-725.patch, solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *rename*: renames a core > h3. CoreAdminHandler: handles CoreContainer operations > * *load*/*create*: CoreContainer load > * *unload*: CoreContainer unload > * *reload*: CoreContainer reload > * *swap*: CoreContainer swap > * *alias*: CoreContainer alias > * *unalias*: CoreContainer unalias > * *rename*: CoreContainer rename > * *persist*: CoreContainer persist, writes the solr.xml > **stauts*: returns the status of all/one SolrCore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-734) NPE in SolrCore
[ https://issues.apache.org/jira/browse/SOLR-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626520#action_12626520 ] Henri Biestro commented on SOLR-734: It should not be possible to build a SolrCore with a null CoreDescriptor (the ctor that explicitly passes a null should never be called). Could you give a bit more of information on your case? > NPE in SolrCore > --- > > Key: SOLR-734 > URL: https://issues.apache.org/jira/browse/SOLR-734 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Nikhil Chhaochharia > Fix For: 1.3 > > > SolrCore.getStatistics() calls > getCoreDescriptor().getCoreContainer().getCoreNames(this) without checking if > the CoreDescriptor is null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-725: --- Description: These 3 classes and the name vs alias handling are somewhat confusing. The recent SOLR-647 & SOLR-716 have created a bit of a flux. This issue attemps to clarify the model and the list of operations. h3. CoreDescriptor: describes the parameters of a SolrCore h4. Definitions * has one name ** The CoreDescriptor name may represent multiple aliases; in that case, first alias is the SolrCore name * has one instance directory location * has one config & schema name h4. Operations The class is only a parameter passing facility h3. SolrCore: manages a Lucene index h4. Definitions * has one unique *name* (in the CoreContainer) ** the *name* is used in JMX to identify the core * has one current set of *aliases* ** the name is the first alias h4. Name & alias operations * *get name/aliases*: obvious * *alias*: adds an alias to this SolrCore * *unalias*: removes an alias from this SolrCore * *name*: sets the SolrCore name ** potentially impacts JMX registration * *rename*: picks a new name from the SolrCore aliases ** triggered when alias name is already in use h3. CoreContainer: manages all relations between cores & descriptors h4. Definitions * has a set of aliases (each of them pointing to one core) ** ensure alias uniqueness. h4. SolrCore instance operations * *load*: makes a SolrCore available for requests ** creates a SolrCore ** registers all SolrCore aliases in the aliases set ** (load = create + register) * *unload*: removes a core idenitified by one of its aliases ** stops handling the Lucene index ** all SolrCore aliases are removed * *reload*: recreate the core identified by one of its aliases * *create*: create a core from a CoreDescriptor ** readies up the Lucene index * *register*: registers all aliases of a SolrCore h4. SolrCore alias operations * *swap*: swaps 2 aliases ** method: swap * *alias*: creates 1 alias for a core, potentially unaliasing a previously used alias ** The SolrCore name being an alias, this operation might trigger a SolrCore rename * *unalias*: removes 1 alias for a core ** The SolrCore name being an alias, this operation might trigger a SolrCore rename * *rename*: renames a core h3. CoreAdminHandler: handles CoreContainer operations * *load*/*create*: CoreContainer load * *unload*: CoreContainer unload * *reload*: CoreContainer reload * *swap*: CoreContainer swap * *alias*: CoreContainer alias * *unalias*: CoreContainer unalias * *rename*: CoreContainer rename * *persist*: CoreContainer persist, writes the solr.xml **stauts*: returns the status of all/one SolrCore was: These 3 classes and the name vs alias handling are somewhat confusing. The recent SOLR-647 & SOLR-716 have created a bit of a flux. This issue attemps to clarify the model and the list of operations. h3. CoreDescriptor: describes the parameters of a SolrCore h4. Definitions * has one name ** The CoreDescriptor name may represent multiple aliases; in that case, first alias is the SolrCore name * has one instance directory location * has one config & schema name h4. Operations The class is only a parameter passing facility h3. SolrCore: manages a Lucene index h4. Definitions * has one unique *name* (in the CoreContainer) ** the *name* is used in JMX to identify the core * has one current set of *aliases* ** the name is the first alias h4. Name & alias operations * *get name/aliases*: obvious * *alias*: adds an alias to this SolrCore * *unalias*: removes an alias from this SolrCore * *name*: sets the SolrCore name ** potentially impacts JMX registration * *rename*: picks a new name from the SolrCore aliases ** triggered when alias name is already in use h3. CoreContainer: manages all relations between cores & descriptors h4. Definitions * has a set of aliases (each of them pointing to one core) ** ensure alias uniqueness. h4. SolrCore instance operations * *load*: makes a SolrCore available for requests ** creates a SolrCore ** registers all SolrCore aliases in the aliases set ** (load = create + register) * *unload*: removes a core idenitified by one of its aliases ** stops handling the Lucene index ** all SolrCore aliases are removed * *reload*: recreate the core identified by one of its aliases * *create*: create a core from a CoreDescriptor ** readies up the Lucene index
[jira] Updated: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-725: --- Attachment: solr-725.patch updated to include part of solr-731 changes (aka CoreDescriptor.getCoreContainer is not public; ctor does not use a CoreContainer) > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch, solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626219#action_12626219 ] Henri Biestro commented on SOLR-725: Paul, The core always has a name; if you use that name to point to another core, well, that name will point to something else. Whether its JMX or solr-561. I dont see how aliases are different than the name itself; you already can have these problems with swap so these are not new ones. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626209#action_12626209 ] henrib edited comment on SOLR-725 at 8/27/08 10:51 AM: -- bq. A rename with null is a bad usecase . We should not allow it rename is a package private method that is called when we unalias a core from its name, asking it to pick a new one from its aliases. However, is there is no alias to that core, the core has no way to name itself anymore but it may still be serving requests; thus the 'null' to indicate that case. I'd expect this to be rare but the case exists nevertheless. was (Author: henrib): bq. A rename with null is a bad usecase . We should not allow it rename is a package private method that is called when we unalias a core from its name, asking it to pick a new one from its aliases. However, is there is no alias to that core, the core has no way to name itself anymore but it may still be serving requests. I'd expect this to be rare but the case exists nevertheless. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626209#action_12626209 ] Henri Biestro commented on SOLR-725: bq. A rename with null is a bad usecase . We should not allow it rename is a package private method that is called when we unalias a core from its name, asking it to pick a new one from its aliases. However, is there is no alias to that core, the core has no way to name itself anymore but it may still be serving requests. I'd expect this to be rare but the case exists nevertheless. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-731) CoreDescriptor.getCoreContainer should not be public
[ https://issues.apache.org/jira/browse/SOLR-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-731: --- Attachment: solr-731.patch A patch that fixes this issue. As a strawman feature, this completely removes the necessity to keep a CoreDescriptor in the SolrCore. For compatibility, CoreContainer.describe() can recreate the CoreDescriptor (test case through reload). Refactoring occuring outside of SolrCore/CoreContainer/CoreDescriptor are consequences of reducing public exposures of some methods > CoreDescriptor.getCoreContainer should not be public > > > Key: SOLR-731 > URL: https://issues.apache.org/jira/browse/SOLR-731 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-731.patch > > > For the very same reasons that CoreDescriptor.getCoreProperties did not need > to be public (aka SOLR-724) > It also means the CoreDescriptor ctor should not need a CoreContainer > The CoreDescriptor is only meant to be describing a "to-be created SolrCore". > However, we need access to the CoreContainer from the SolrCore now that we > are guaranteed the CoreContainer always exists. > This is also a natural consequence of SOLR-647 now that the CoreContainer is > not a map of CoreDescriptor but a map of SolrCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626188#action_12626188 ] Henri Biestro commented on SOLR-725: The rename with null can only occur if the core *name* is going to be used out by another core *alias*. Fixing point 1. moots point 2. I still don't get the compelling reason to switch to the symlink model but besides being different, there is no compelling advantage to the hardlink model that I can see either. So, assuming symlink would be the choice, the only added constraints to the model are that *alias/unalias* can not operate or modify a core *name*. Besides Paul & I, any comment ? > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-723) SolrCore & aliasing/swapping may lead to confusing JMX
[ https://issues.apache.org/jira/browse/SOLR-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626178#action_12626178 ] Henri Biestro commented on SOLR-723: The other simpler approach is just to state that the core *name* is immutable. Which would make this issue a moot point. > SolrCore & aliasing/swapping may lead to confusing JMX > -- > > Key: SOLR-723 > URL: https://issues.apache.org/jira/browse/SOLR-723 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Henri Biestro >Priority: Minor > > As mentioned by Yonik in SOLR-647, JMX registers the core with its name. > After swapping or re-aliasing the core, the JMX tracking name does not > correspond to the actual core anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-731) CoreDescriptor.getCoreContainer should not be public
CoreDescriptor.getCoreContainer should not be public Key: SOLR-731 URL: https://issues.apache.org/jira/browse/SOLR-731 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Henri Biestro For the very same reasons that CoreDescriptor.getCoreProperties did not need to be public (aka SOLR-724) It also means the CoreConstructor ctor should not need a CoreContainer The CoreDescriptor is only meant to be describing a "to-be created SolrCore". However, we need access to the CoreContainer from the SolrCore now that we are guaranteed the CoreContainer always exists. This is also a natural consequence of solr-647 now that the CoreContainer is not a map of CoreDescriptor but a map of SolrCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-731) CoreDescriptor.getCoreContainer should not be public
[ https://issues.apache.org/jira/browse/SOLR-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-731: --- Description: For the very same reasons that CoreDescriptor.getCoreProperties did not need to be public (aka SOLR-724) It also means the CoreDescriptor ctor should not need a CoreContainer The CoreDescriptor is only meant to be describing a "to-be created SolrCore". However, we need access to the CoreContainer from the SolrCore now that we are guaranteed the CoreContainer always exists. This is also a natural consequence of SOLR-647 now that the CoreContainer is not a map of CoreDescriptor but a map of SolrCore. was: For the very same reasons that CoreDescriptor.getCoreProperties did not need to be public (aka SOLR-724) It also means the CoreConstructor ctor should not need a CoreContainer The CoreDescriptor is only meant to be describing a "to-be created SolrCore". However, we need access to the CoreContainer from the SolrCore now that we are guaranteed the CoreContainer always exists. This is also a natural consequence of SOLR-647 now that the CoreContainer is not a map of CoreDescriptor but a map of SolrCore. > CoreDescriptor.getCoreContainer should not be public > > > Key: SOLR-731 > URL: https://issues.apache.org/jira/browse/SOLR-731 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Henri Biestro > > For the very same reasons that CoreDescriptor.getCoreProperties did not need > to be public (aka SOLR-724) > It also means the CoreDescriptor ctor should not need a CoreContainer > The CoreDescriptor is only meant to be describing a "to-be created SolrCore". > However, we need access to the CoreContainer from the SolrCore now that we > are guaranteed the CoreContainer always exists. > This is also a natural consequence of SOLR-647 now that the CoreContainer is > not a map of CoreDescriptor but a map of SolrCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-731) CoreDescriptor.getCoreContainer should not be public
[ https://issues.apache.org/jira/browse/SOLR-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-731: --- Description: For the very same reasons that CoreDescriptor.getCoreProperties did not need to be public (aka SOLR-724) It also means the CoreConstructor ctor should not need a CoreContainer The CoreDescriptor is only meant to be describing a "to-be created SolrCore". However, we need access to the CoreContainer from the SolrCore now that we are guaranteed the CoreContainer always exists. This is also a natural consequence of SOLR-647 now that the CoreContainer is not a map of CoreDescriptor but a map of SolrCore. was: For the very same reasons that CoreDescriptor.getCoreProperties did not need to be public (aka SOLR-724) It also means the CoreConstructor ctor should not need a CoreContainer The CoreDescriptor is only meant to be describing a "to-be created SolrCore". However, we need access to the CoreContainer from the SolrCore now that we are guaranteed the CoreContainer always exists. This is also a natural consequence of solr-647 now that the CoreContainer is not a map of CoreDescriptor but a map of SolrCore. > CoreDescriptor.getCoreContainer should not be public > > > Key: SOLR-731 > URL: https://issues.apache.org/jira/browse/SOLR-731 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Henri Biestro > > For the very same reasons that CoreDescriptor.getCoreProperties did not need > to be public (aka SOLR-724) > It also means the CoreConstructor ctor should not need a CoreContainer > The CoreDescriptor is only meant to be describing a "to-be created SolrCore". > However, we need access to the CoreContainer from the SolrCore now that we > are guaranteed the CoreContainer always exists. > This is also a natural consequence of SOLR-647 now that the CoreContainer is > not a map of CoreDescriptor but a map of SolrCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626112#action_12626112 ] Henri Biestro commented on SOLR-725: Paul- We are not removing any of these methods but we do need to clarify CoreDescriptor usage. CoreDescriptor.getName() is not used besides when loading a SolrCore which is exactly what it should solely be used for ; CoreDescriptor is *only* a SolrCore creation parameter, using it for any other purpose is not a good idea. When you need the SolrCore *name* (not all its *aliases*), you should use SolrCore.getName(). The SolrCore *name* is merely the first *alias* and the one used to identify the SolrCore to JMX. The hard-link model is implemented with this patch and avoids the functional complexity of added complexity of 'alias/unalias' should not rename, etc; although I don't doubt it's easy to implement the sym-link model, imho we are still missing a compelling reason to do so. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625805#action_12625805
]
Henri Biestro commented on SOLR-725:
Shalin -
We decref the counter appropriately (registerNotSynchronized does not do it) or
I just dont see the issue so I 'll assume that what bothers you is that
unaliasing a core should not have the potential effect of closing it.
If we use Yonik's model, there is no reason not to; the model is akin to the
inode / hard-link model on Unix. The inode in our case is the Lucene index (the
dataDir, managed by the SolrCore) - and the aliases are the hardlinks. If you
remove all links (unalias all aliases), the inode (of the Lucene index) goes
away. Even if the unlink (unalias) is the side effect of another 'ln' (alias).
A symbolic link model - as Paul proposes - is a different one.
I don't get yet what the hard-link/Yonik's model problem is which I'd find
useful to understand .
Paul -
bq. But as things stand we are removing some commonly useful methods
Which ones? Is it something that impacts solr-561 somehow?
Btw, your example started using the alias *feature* ,( not the alias
*command*), creating a core with name 'version-3.0' and alias 'dev'
(*1-create('version-3.0,dev') *); thus the difficulty to get your previous
point.
> CoreContainer/CoreDescriptor/SolrCore cleansing
> ---
>
> Key: SOLR-725
> URL: https://issues.apache.org/jira/browse/SOLR-725
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Henri Biestro
> Attachments: solr-725.patch
>
>
> These 3 classes and the name vs alias handling are somewhat confusing.
> The recent SOLR-647 & SOLR-716 have created a bit of a flux.
> This issue attemps to clarify the model and the list of operations.
> h3. CoreDescriptor: describes the parameters of a SolrCore
> h4. Definitions
> * has one name
> ** The CoreDescriptor name may represent multiple aliases; in that
> case, first alias is the SolrCore name
> * has one instance directory location
> * has one config & schema name
> h4. Operations
> The class is only a parameter passing facility
> h3. SolrCore: manages a Lucene index
> h4. Definitions
> * has one unique *name* (in the CoreContainer)
> **the *name* is used in JMX to identify the core
> * has one current set of *aliases*
> **the name is the first alias
> h4. Name & alias operations
> * *get name/aliases*: obvious
> * *alias*: adds an alias to this SolrCore
> * *unalias*: removes an alias from this SolrCore
> * *name*: sets the SolrCore name
> **potentially impacts JMX registration
> * *rename*: picks a new name from the SolrCore aliases
> **triggered when alias name is already in use
> h3. CoreContainer: manages all relations between cores & descriptors
> h4. Definitions
> * has a set of aliases (each of them pointing to one core)
> **ensure alias uniqueness.
> h4. SolrCore instance operations
> * *load*: makes a SolrCore available for requests
> **creates a SolrCore
> **registers all SolrCore aliases in the aliases set
> **(load = create + register)
> * *unload*: removes a core idenitified by one of its aliases
> **stops handling the Lucene index
> **all SolrCore aliases are removed
> * *reload*: recreate the core identified by one of its aliases
> * *create*: create a core from a CoreDescriptor
> **readies up the Lucene index
> * *register*: registers all aliases of a SolrCore
>
> h4. SolrCore alias operations
> * *swap*: swaps 2 aliases
> **method: swap
> * *alias*: creates 1 alias for a core, potentially unaliasing a
> previously used alias
> **The SolrCore name being an alias, this operation might trigger
> a SolrCore rename
> * *unalias*: removes 1 alias for a core
> **The SolrCore name being an alias, this operation might trigger
> a SolrCore rename
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-723) SolrCore & aliasing/swapping may lead to confusing JMX
[ https://issues.apache.org/jira/browse/SOLR-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625719#action_12625719 ] Henri Biestro commented on SOLR-723: Yonik's comment in solr-725 makes an analogy between name/aliases and the SolrCore that's close to what hard-links are to inodes. What if we were to consider the 'inode' as the sole think that really uniquely identifies a SolrCore, that is it's dataDir? The SolrCore *name* would not be used for that purpose and would only happen to be the first alias (as it stands now). This would allow solving this issue by changing how we register a core into JMX (with its relative path to the solr.solr.home dir or something close to that) and have no swapping, etc. Just a thought. > SolrCore & aliasing/swapping may lead to confusing JMX > -- > > Key: SOLR-723 > URL: https://issues.apache.org/jira/browse/SOLR-723 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Henri Biestro >Priority: Minor > > As mentioned by Yonik in SOLR-647, JMX registers the core with its name. > After swapping or re-aliasing the core, the JMX tracking name does not > correspond to the actual core anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-723) SolrCore & aliasing/swapping may lead to confusing JMX
[ https://issues.apache.org/jira/browse/SOLR-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625719#action_12625719 ] henrib edited comment on SOLR-723 at 8/26/08 6:06 AM: - Yonik's comment in solr-725 makes an analogy between name/aliases and the SolrCore that's close to what hard-links are to inodes. What if we were to consider the 'inode' as the sole think that really uniquely identifies a SolrCore, that is it's *dataDir*? The SolrCore *name* would not be used for that purpose and would only happen to be the first alias (as it stands now). This would allow solving this issue by changing how we register a core into JMX (with its relative path to the solr.solr.home dir or something close to that) and have no swapping, etc. Just a thought. was (Author: henrib): Yonik's comment in solr-725 makes an analogy between name/aliases and the SolrCore that's close to what hard-links are to inodes. What if we were to consider the 'inode' as the sole think that really uniquely identifies a SolrCore, that is it's dataDir? The SolrCore *name* would not be used for that purpose and would only happen to be the first alias (as it stands now). This would allow solving this issue by changing how we register a core into JMX (with its relative path to the solr.solr.home dir or something close to that) and have no swapping, etc. Just a thought. > SolrCore & aliasing/swapping may lead to confusing JMX > -- > > Key: SOLR-723 > URL: https://issues.apache.org/jira/browse/SOLR-723 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Henri Biestro >Priority: Minor > > As mentioned by Yonik in SOLR-647, JMX registers the core with its name. > After swapping or re-aliasing the core, the JMX tracking name does not > correspond to the actual core anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625541#action_12625541 ] Henri Biestro commented on SOLR-725: Otis, this does not hold releasing 1.3; I'm glad solr-724 got solved. I just wish it will be easier (& faster) to release 1.3.1. :-) Shalin, I'll do my best about solr-723; but again, this should not hold releasing 1.3. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-724) CoreDescriptor.{get,set}CoreProperties should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625377#action_12625377
]
Henri Biestro commented on SOLR-724:
Obviously different :-)
In my mind, these are resources of the core-container / cores; resources are
accessed through their respective ResourceLoader.
And the CoreDescriptor is, at its name hints, a parameter; it should not play
any active role besides carrying data to create a SolrCore (and should not be
used beyond that role).
> CoreDescriptor.{get,set}CoreProperties should probably not be public (but
> package private)
> --
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-724) CoreDescriptor.{get,set}CoreProperties should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625346#action_12625346
]
Henri Biestro commented on SOLR-724:
When a method is public, it also has to be maintained & up-compatible; if you
write a component that uses some private methods or members, that's your
prerogative but there is no guarantee from Apache that it's existence and
behavior will remain in the future.
In this issue, I'm stating that exposing Properties in the CoreDescriptor is
hindering future evolution because they will have to be maintained, that the
same information should be available from what I consider a narrower scope
location that does not reduce the functional possibilities.
> CoreDescriptor.{get,set}CoreProperties should probably not be public (but
> package private)
> --
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625347#action_12625347 ] Henri Biestro commented on SOLR-725: bq . This does not look like a useful way of using aliases. This is one extra step which could have been avoided. You used aliases in your own example. So I must have missed your point. bq. We just blindly do a reload assuming everything is fine. So no testing. Your operational rules are different than those I'm constrained to. I'm merely trying to contribute back the solution to some problems I've encountered. bq . the alias feature is implemented in a very wrong way Again, this is what this issue attempts to address. It's not intended to be confrontational. bq. I am yet to see a valid usecase. Besides those already mentioned (& I guess Yonik may have more since he introduced aliasessolving solr-647), there are plenty of other features that can come out from having a different path to use the same core; security, rendering, etc. Courtesy aside, I do respect functional needs of others & their implications although I don't understand all of them; I wish this was a community value. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625317#action_12625317 ] Henri Biestro commented on SOLR-725: bq. What we do is after we make the necessary changes do a reload. You lost me here; reindexing implies you loaded the core already. Guess you mean that *after* reindexing, you can replicate & slaves only have to reload? bq. is it not possible with the following steps? Correct, this is another useful way of using aliases to achieve the same. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-724) CoreDescriptor.{get,set}CoreProperties should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625305#action_12625305
]
Henri Biestro commented on SOLR-724:
I'm confused about when the 'what-if' rule can apply or not wrt public methods.
My understanding was that till a use-case exists, we shouldn't publicly expose
the method ( and it's been quite a hard lesson... :-) )
Besides, the SolrResourceLoader *is* available from everywhere.
> CoreDescriptor.{get,set}CoreProperties should probably not be public (but
> package private)
> --
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625304#action_12625304
]
Henri Biestro commented on SOLR-725:
About being inconsistent, this is what this issue attempts to solve. :-)
And, yes, aliasing is a usefull feature: this allows to have one webapp path
that's constant for users (or links to persist) and allows to change the index
when reindexing is needed (reload is only good enough for non-schema related
modifications) without fuss..
Say you have your core declared as:
{code:xml}
{code}
Users refer to it through its *public* alias.
When you make schema/indexing changes that necessitate reindexing (hcnage
stopwords, stemming, etc):
# create your new core as 'version-3.0,dev'
# reindex the content
# verify your preferred queries do work appropriately
# alias('public', 'versions-3.0') ; which changes the link to point to the new
version and closes the old one (as soon as all queries have finished running)
# unalias('dev'); so you are ready for next version
> CoreContainer/CoreDescriptor/SolrCore cleansing
> ---
>
> Key: SOLR-725
> URL: https://issues.apache.org/jira/browse/SOLR-725
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Henri Biestro
> Attachments: solr-725.patch
>
>
> These 3 classes and the name vs alias handling are somewhat confusing.
> The recent SOLR-647 & SOLR-716 have created a bit of a flux.
> This issue attemps to clarify the model and the list of operations.
> h3. CoreDescriptor: describes the parameters of a SolrCore
> h4. Definitions
> * has one name
> ** The CoreDescriptor name may represent multiple aliases; in that
> case, first alias is the SolrCore name
> * has one instance directory location
> * has one config & schema name
> h4. Operations
> The class is only a parameter passing facility
> h3. SolrCore: manages a Lucene index
> h4. Definitions
> * has one unique *name* (in the CoreContainer)
> **the *name* is used in JMX to identify the core
> * has one current set of *aliases*
> **the name is the first alias
> h4. Name & alias operations
> * *get name/aliases*: obvious
> * *alias*: adds an alias to this SolrCore
> * *unalias*: removes an alias from this SolrCore
> * *name*: sets the SolrCore name
> **potentially impacts JMX registration
> * *rename*: picks a new name from the SolrCore aliases
> **triggered when alias name is already in use
> h3. CoreContainer: manages all relations between cores & descriptors
> h4. Definitions
> * has a set of aliases (each of them pointing to one core)
> **ensure alias uniqueness.
> h4. SolrCore instance operations
> * *load*: makes a SolrCore available for requests
> **creates a SolrCore
> **registers all SolrCore aliases in the aliases set
> **(load = create + register)
> * *unload*: removes a core idenitified by one of its aliases
> **stops handling the Lucene index
> **all SolrCore aliases are removed
> * *reload*: recreate the core identified by one of its aliases
> * *create*: create a core from a CoreDescriptor
> **readies up the Lucene index
> * *register*: registers all aliases of a SolrCore
>
> h4. SolrCore alias operations
> * *swap*: swaps 2 aliases
> **method: swap
> * *alias*: creates 1 alias for a core, potentially unaliasing a
> previously used alias
> **The SolrCore name being an alias, this operation might trigger
> a SolrCore rename
> * *unalias*: removes 1 alias for a core
> **The SolrCore name being an alias, this operation might trigger
> a SolrCore rename
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-724) CoreDescriptor.{get,set}CoreProperties should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-724:
---
Summary: CoreDescriptor.{get,set}CoreProperties should probably not be
public (but package private) (was: CoreDescriptor.{get,set}CoreExpressions
should probably not be public (but package private))
> CoreDescriptor.{get,set}CoreProperties should probably not be public (but
> package private)
> --
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-724) CoreDescriptor.{get,set}CoreExpressions should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625287#action_12625287
]
Henri Biestro commented on SOLR-724:
Yes, correct; properties, not expressions.
They are unnecessary since the CoreContainer & each SolrCore resource loader
could (will hopefully) contain the evaluated properties.
That would make 2 places where we can access them & this seems redundant.
I'm just trying to reduce public method exposure.
> CoreDescriptor.{get,set}CoreExpressions should probably not be public (but
> package private)
> ---
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-725: --- Attachment: solr-725.patch The patch solves the 3 issues this relates to. The SolrCore handles its name & makes JMX follow potential renames. CoreDescriptor does not expose more than necessary (& protects the possibility of SOLR-646 property expression features). CoreContainer is refactored to be a bit more efficient wrt cores locking & SolrCore alias/name handling. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
CoreContainer/CoreDescriptor/SolrCore cleansing --- Key: SOLR-725 URL: https://issues.apache.org/jira/browse/SOLR-725 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Reporter: Henri Biestro These 3 classes and the name vs alias handling are somewhat confusing. The recent SOLR-647 & SOLR-716 have created a bit of a flux. This issue attemps to clarify the model and the list of operations. h3. CoreDescriptor: describes the parameters of a SolrCore h4. Definitions * has one name ** The CoreDescriptor name may represent multiple aliases; in that case, first alias is the SolrCore name * has one instance directory location * has one config & schema name h4. Operations The class is only a parameter passing facility h3. SolrCore: manages a Lucene index h4. Definitions * has one unique *name* (in the CoreContainer) ** the *name* is used in JMX to identify the core * has one current set of *aliases* ** the name is the first alias h4. Name & alias operations * *get name/aliases*: obvious * *alias*: adds an alias to this SolrCore * *unalias*: removes an alias from this SolrCore * *name*: sets the SolrCore name ** potentially impacts JMX registration * *rename*: picks a new name from the SolrCore aliases ** triggered when alias name is already in use h3. CoreContainer: manages all relations between cores & descriptors h4. Definitions * has a set of aliases (each of them pointing to one core) ** ensure alias uniqueness. h4. SolrCore instance operations * *load*: makes a SolrCore available for requests ** creates a SolrCore ** registers all SolrCore aliases in the aliases set ** (load = create + register) * *unload*: removes a core idenitified by one of its aliases ** stops handling the Lucene index ** all SolrCore aliases are removed * *reload*: recreate the core identified by one of its aliases * *create*: create a core from a CoreDescriptor ** readies up the Lucene index * *register*: registers all aliases of a SolrCore h4. SolrCore alias operations * *swap*: swaps 2 aliases ** method: swap * *alias*: creates 1 alias for a core, potentially unaliasing a previously used alias ** The SolrCore name being an alias, this operation might trigger a SolrCore rename * *unalias*: removes 1 alias for a core ** The SolrCore name being an alias, this operation might trigger a SolrCore rename -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-724) CoreDescriptor.{get,set}CoreExpressions should probably not be public (but package private)
CoreDescriptor.{get,set}CoreExpressions should probably not be public (but
package private)
---
Key: SOLR-724
URL: https://issues.apache.org/jira/browse/SOLR-724
Project: Solr
Issue Type: Bug
Affects Versions: 1.3
Reporter: Henri Biestro
Priority: Minor
Exposing them precludes being ever able to fill the CoreDescriptor with
property expressions.
Since a 'public' method can not be removed easily, this is a future problem.
Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-723) SolrCore & aliasing/swapping may lead to confusing JMX
SolrCore & aliasing/swapping may lead to confusing JMX -- Key: SOLR-723 URL: https://issues.apache.org/jira/browse/SOLR-723 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Henri Biestro Priority: Minor As mentioned by Yonik in SOLR-647, JMX registers the core with its name. After swapping or re-aliasing the core, the JMX tracking name does not correspond to the actual core anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-722) CoreContainer.reload should make core aliases point to reloaded core
CoreContainer.reload should make core aliases point to reloaded core Key: SOLR-722 URL: https://issues.apache.org/jira/browse/SOLR-722 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Henri Biestro CoreContainer.reload does only make the SolrCore name point to the reloaded core. Since loading (creating) a core creates all aliases for that core, reload should do the same. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SOLR-715) CoreDescriptor should fully describe what is necessary to create/re-create a SolrCore
[ https://issues.apache.org/jira/browse/SOLR-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro closed SOLR-715. -- Resolution: Incomplete Not proper scope, will reformulate > CoreDescriptor should fully describe what is necessary to create/re-create a > SolrCore > - > > Key: SOLR-715 > URL: https://issues.apache.org/jira/browse/SOLR-715 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro >Priority: Minor > > Before core 'aliasing' was introduced, the following were true: > There is one CoreDescriptor per SolCore > The SolrDescriptor fully describes the data needed to create/re-create a > SolrCore. > The CoreDescriptor does not fully describe the data needed to > create/re-create a SolrCore since only the 'name' (aka the 1st alias) is used > in the CoreDescirptor constructor.. > It is then not possible anymore to create dynamically a SolrCore with > multiple aliases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-721) DirectSolrConnection is broken - missing CoreContainer initialization
[
https://issues.apache.org/jira/browse/SOLR-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-721:
---
Description:
It might be initialized in such a way that no core container is created.
Adding the proper includes & a member:
{code}
final CoreContainer cores;
{code}
And modifying the constructor:
{code}
public DirectSolrConnection( String instanceDir, String dataDir, String
loggingPath )
{
// If a loggingPath is specified, try using that (this needs to happen
first)
if( loggingPath != null ) {
File loggingConfig = new File( loggingPath );
if( !loggingConfig.exists() && instanceDir != null ) {
loggingConfig = new File( new File(instanceDir), loggingPath );
}
if( loggingConfig.exists() ) {
System.setProperty("java.util.logging.config.file",
loggingConfig.getAbsolutePath() );
}
else {
throw new SolrException( SolrException.ErrorCode.SERVER_ERROR, "can not
find logging file: "+loggingConfig );
}
}
// Initialize CoreContainer
try {
cores = new CoreContainer(new
SolrResourceLoader(SolrResourceLoader.locateInstanceDir()));
SolrConfig solrConfig = new SolrConfig(instanceDir,
SolrConfig.DEFAULT_CONF_FILE, null);
CoreDescriptor dcore = new CoreDescriptor(cores, "",
solrConfig.getResourceLoader().getInstanceDir());
IndexSchema indexSchema = new IndexSchema(solrConfig,
instanceDir+"/conf/schema.xml", null);
core = new SolrCore( null, dataDir, solrConfig, indexSchema, dcore);
cores.register("", core, false);
parser = new SolrRequestParsers( config );
}
catch (Exception ee) {
throw new RuntimeException(ee);
}
}
{code}
Should take care of this case.
was:
It might be initialized in such a way that no core container is created.
Adding the proper includes & a member:
{code}
final CoreContainer cores;
{code}
And modifying the constructor:
{code}
public DirectSolrConnection( String instanceDir, String dataDir, String
loggingPath )
{
// If a loggingPath is specified, try using that (this needs to happen
first)
if( loggingPath != null ) {
File loggingConfig = new File( loggingPath );
if( !loggingConfig.exists() && instanceDir != null ) {
loggingConfig = new File( new File(instanceDir), loggingPath );
}
if( loggingConfig.exists() ) {
System.setProperty("java.util.logging.config.file",
loggingConfig.getAbsolutePath() );
}
else {
throw new SolrException( SolrException.ErrorCode.SERVER_ERROR, "can not
find logging file: "+loggingConfig );
}
}
// Initialize SolrConfig
SolrConfig config = null;
try {
cores = new CoreContainer(new
SolrResourceLoader(SolrResourceLoader.locateInstanceDir()));
SolrConfig solrConfig = new SolrConfig(instanceDir,
SolrConfig.DEFAULT_CONF_FILE, null);
CoreDescriptor dcore = new CoreDescriptor(cores, "",
solrConfig.getResourceLoader().getInstanceDir());
IndexSchema indexSchema = new IndexSchema(solrConfig,
instanceDir+"/conf/schema.xml", null);
core = new SolrCore( null, dataDir, solrConfig, indexSchema, dcore);
cores.register("", core, false);
parser = new SolrRequestParsers( config );
}
catch (Exception ee) {
throw new RuntimeException(ee);
}
}
{code}
Should take care of this case.
> DirectSolrConnection is broken - missing CoreContainer initialization
> -
>
> Key: SOLR-721
> URL: https://issues.apache.org/jira/browse/SOLR-721
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
> Fix For: 1.4
>
>
> It might be initialized in such a way that no core container is created.
> Adding the proper includes & a member:
> {code}
> final CoreContainer cores;
> {code}
> And modifying the constructor:
> {code}
> public DirectSolrConnection( String instanceDir, String dataDir, String
> loggingPath )
> {
> // If a loggingPath is specified, try using that (this needs to happen
> first)
> if( loggingPath != null ) {
> File loggingConfig = new File( loggingPath );
> if( !loggingConfig.exists() && instanceDir != null ) {
> loggingConfig = new File( new File(instanceDir), loggingPath );
> }
> if( loggingConfig.exists() ) {
> System.setProperty("java.util.logging.config.file",
> loggingConfig.getAbsolutePath() );
> }
> else {
> throw new SolrException( SolrException.ErrorCode.SERVER_ERROR, "can
> not find logging file: "+loggingConfig );
> }
> }
>
> // Initialize CoreContainer
> try {
> cores = new CoreContainer(new
> SolrResourceLoader(SolrResourceLoader.locateInstanceDir()));
> SolrConfig solrConfig
[jira] Created: (SOLR-721) DirectSolrConnection is broken - missing CoreContainer initialization
DirectSolrConnection is broken - missing CoreContainer initialization
-
Key: SOLR-721
URL: https://issues.apache.org/jira/browse/SOLR-721
Project: Solr
Issue Type: Bug
Affects Versions: 1.3
Reporter: Henri Biestro
Fix For: 1.4
It might be initialized in such a way that no core container is created.
Adding the proper includes & a member:
{code}
final CoreContainer cores;
{code}
And modifying the constructor:
{code}
public DirectSolrConnection( String instanceDir, String dataDir, String
loggingPath )
{
// If a loggingPath is specified, try using that (this needs to happen
first)
if( loggingPath != null ) {
File loggingConfig = new File( loggingPath );
if( !loggingConfig.exists() && instanceDir != null ) {
loggingConfig = new File( new File(instanceDir), loggingPath );
}
if( loggingConfig.exists() ) {
System.setProperty("java.util.logging.config.file",
loggingConfig.getAbsolutePath() );
}
else {
throw new SolrException( SolrException.ErrorCode.SERVER_ERROR, "can not
find logging file: "+loggingConfig );
}
}
// Initialize SolrConfig
SolrConfig config = null;
try {
cores = new CoreContainer(new
SolrResourceLoader(SolrResourceLoader.locateInstanceDir()));
SolrConfig solrConfig = new SolrConfig(instanceDir,
SolrConfig.DEFAULT_CONF_FILE, null);
CoreDescriptor dcore = new CoreDescriptor(cores, "",
solrConfig.getResourceLoader().getInstanceDir());
IndexSchema indexSchema = new IndexSchema(solrConfig,
instanceDir+"/conf/schema.xml", null);
core = new SolrCore( null, dataDir, solrConfig, indexSchema, dcore);
cores.register("", core, false);
parser = new SolrRequestParsers( config );
}
catch (Exception ee) {
throw new RuntimeException(ee);
}
}
{code}
Should take care of this case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-719) Persisting solr.xml through SolrJ does not handle relative pathes correctly
[
https://issues.apache.org/jira/browse/SOLR-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-719:
---
Affects Version/s: (was: 1.4)
1.3
> Persisting solr.xml through SolrJ does not handle relative pathes correctly
> ---
>
> Key: SOLR-719
> URL: https://issues.apache.org/jira/browse/SOLR-719
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Trivial
> Fix For: 1.4
>
>
> It seems the code in CoreContainer.persistFile should begin with:
> {code}
> /** Persists the cores config file in a user provided file. */
> public void persistFile(File file) {
> if (file != null && !file.isAbsolute())
> file = new File(configFile.getParentFile(), file.getPath());
> log.info("Persisting cores config to " + (file==null ? configFile :
> file));
> ...
> {code}
> The issue today resides in calling file.getName() instead of file.getPath()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-720) Persistence does not write the expected XML
[
https://issues.apache.org/jira/browse/SOLR-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-720:
---
Affects Version/s: (was: 1.4)
1.3
> Persistence does not write the expected XML
> ---
>
> Key: SOLR-720
> URL: https://issues.apache.org/jira/browse/SOLR-720
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Critical
> Fix For: 1.4
>
>
> CoreContainer.persist() writes the core container properties at the 'wrong'
> place in the XML.
> A Solr webapp with a solr.xml stating persistent='true' may fail to restart
> if the file is written.
> They should be written under /solr - not /solr/cores aka before (not after):
> {code}
> /** Write the cores configuration through a writer.*/
> void persist(Writer writer) throws IOException {
> ...
> writer.write("
[jira] Created: (SOLR-720) Persistence does not write the expected XML
Persistence does not write the expected XML
---
Key: SOLR-720
URL: https://issues.apache.org/jira/browse/SOLR-720
Project: Solr
Issue Type: Bug
Affects Versions: 1.4
Reporter: Henri Biestro
Priority: Critical
Fix For: 1.4
CoreContainer.persist() writes the core container properties at the 'wrong'
place in the XML.
A Solr webapp with a solr.xml stating persistent='true' may fail to restart if
the file is written.
They should be written under /solr - not /solr/cores aka before (not after):
{code}
/** Write the cores configuration through a writer.*/
void persist(Writer writer) throws IOException {
...
writer.write("
[jira] Created: (SOLR-719) Persisting solr.xml through SolrJ does not handle relative pathes correctly
Persisting solr.xml through SolrJ does not handle relative pathes correctly
---
Key: SOLR-719
URL: https://issues.apache.org/jira/browse/SOLR-719
Project: Solr
Issue Type: Bug
Affects Versions: 1.4
Reporter: Henri Biestro
Priority: Trivial
Fix For: 1.4
It seems the code in CoreContainer.persistFile should begin with:
{code}
/** Persists the cores config file in a user provided file. */
public void persistFile(File file) {
if (file != null && !file.isAbsolute())
file = new File(configFile.getParentFile(), file.getPath());
log.info("Persisting cores config to " + (file==null ? configFile : file));
...
{code}
The issue today resides in calling file.getName() instead of file.getPath()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-646) Configuration properties enhancements in solr.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-646:
---
Summary: Configuration properties enhancements in solr.xml (was:
Configuration properties in multicore.xml)
> Configuration properties enhancements in solr.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: solr-646.patch, solr-646.patch, solr-646.patch,
> SOLR-646.patch, solr-646.patch, solr-646.patch, solr-646.patch,
> solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in *solr.xml*.
> h3. Use cases:
> Describe core data directories from solr.xml as properties.
> Share the same schema and/or config file between multiple cores.
> Share reusable fragments of schema & configuration between multiple cores.
> h3. Usage:
> h4. solr.xml
> This *solr.xml* will be used to illustrates using properties for different
> purpose.
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> {{version}} : if you update your solr.xml or your cores for various motives,
> it can be useful to track of a version. In this example, this will be used to
> define the {{dataDir}} for each core.
> {{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive,
> it might be convenient to use a property that can then be used to describe
> the Solr core name.
> {{instanceDir}}: note that both cores will use the same instance directory,
> sharing their configuration and schema. The {{dataDir}} will be set for each
> of them from the *solrconfig.xml*.
> h4. solrconfig.xml
> This is where our *solr.xml* property are used to define the data directory
> as a composition of, in our example, the language code {{l10n}} and the core
> version stored in {{version}}.
> {code:xml}
>
> ${solr.solr.home}/data/${l10n}-${version}
>
>
> {code}
> h5. schema.xml
> The {{include}} allows to import a file within the schema (or a solrconfig);
> this can help de-clutter long schemas or reuse parts.
> The {{ctlField}} is just illustrating that a field & its type can be set
> through properties as well; in our example, we will want the 'english' core
> to refer to an 'english-configured' field and the 'french' core to a
> 'french-configured' one. The type for the field is defined as {{text-EN}} or
> {{text-FR}} after expansion.
> {code:xml}
>
>
> ...
>
>
>
> ...
>stored="true" multiValued="true" />
>
> {code}
> This schema is importing this *text-l10n.xml* file which is a *fragment*; the
> fragment tag must be present & indicates the file is to be included. Our
> example only defines different stopwords for each language but you could of
> course extend this to stemmers, synonyms, etc.
> {code:xml}
>
>positionIncrementGap="100">
> ...
>words="stopwords-fr.txt"/>
> ...
>
>positionIncrementGap="100">
> ...
>words="stopwords-en.txt"/>
> ...
>
>
> {code}
> Alternatively, one can use XML entities using the 'solr:' protocol to the
> same end as in:
> {code:xml}
>
> ]>
>
>
> omitNorms="true"/>
>
>&textL10n;
>
> ...
>
> {code}
> h4. Technical specifications
> solr.xml can define properties at the multicore & each core level.
> Properties defined in the multicore scope can override system properties.
> Properties defined in a core scope can override multicore & system properties.
> Property definitions can use expressions to define their name & value; these
> expressions are evaluated in their outer scope context .
> CoreContainer serialization keeps properties as defined; persistence is
> idem-potent. (ie property expressions are written, not their evaluation).
> The core descriptor properties are automatically defined in each core
> context, namely:
> solr.core.instanceDir
> solr.core.name
> solr.core.configName
> solr.core.schemaName
> h3. Coding notes:
> - DOMUtil.java:
> cosmetic changes
> toMapExcept systematically skips 'xml:base" attributes (which may come from
> entity resolving)
> - CoreDescriptor.java:
> The core descriptor does not store properties as values but as expressions
> (and all its members can be property expressions as well) allowing to write
> file as defined (not as evaluated)
> The public getC
[jira] Updated: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-646:
---
Description:
This patch refers to 'generalized configuration properties' as specified by
[HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
This means configuration & schema files can use expression based on properties
defined in *solr.xml*.
h3. Use cases:
Describe core data directories from solr.xml as properties.
Share the same schema and/or config file between multiple cores.
Share reusable fragments of schema & configuration between multiple cores.
h3. Usage:
h4. solr.xml
This *solr.xml* will be used to illustrates using properties for different
purpose.
{code:xml}
{code}
{{version}} : if you update your solr.xml or your cores for various motives, it
can be useful to track of a version. In this example, this will be used to
define the {{dataDir}} for each core.
{{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive, it
might be convenient to use a property that can then be used to describe the
Solr core name.
{{instanceDir}}: note that both cores will use the same instance directory,
sharing their configuration and schema. The {{dataDir}} will be set for each of
them from the *solrconfig.xml*.
h4. solrconfig.xml
This is where our *solr.xml* property are used to define the data directory as
a composition of, in our example, the language code {{l10n}} and the core
version stored in {{version}}.
{code:xml}
${solr.solr.home}/data/${l10n}-${version}
{code}
h5. schema.xml
The {{include}} allows to import a file within the schema (or a solrconfig);
this can help de-clutter long schemas or reuse parts.
The {{ctlField}} is just illustrating that a field & its type can be set
through properties as well; in our example, we will want the 'english' core to
refer to an 'english-configured' field and the 'french' core to a
'french-configured' one. The type for the field is defined as {{text-EN}} or
{{text-FR}} after expansion.
{code:xml}
...
...
{code}
This schema is importing this *text-l10n.xml* file which is a *fragment*; the
fragment tag must be present & indicates the file is to be included. Our
example only defines different stopwords for each language but you could of
course extend this to stemmers, synonyms, etc.
{code:xml}
...
...
...
...
{code}
Alternatively, one can use XML entities using the 'solr:' protocol to the same
end as in:
{code:xml}
]>
&textL10n;
...
{code}
h4. Technical specifications
solr.xml can define properties at the multicore & each core level.
Properties defined in the multicore scope can override system properties.
Properties defined in a core scope can override multicore & system properties.
Property definitions can use expressions to define their name & value; these
expressions are evaluated in their outer scope context .
CoreContainer serialization keeps properties as defined; persistence is
idem-potent. (ie property expressions are written, not their evaluation).
The core descriptor properties are automatically defined in each core context,
namely:
solr.core.instanceDir
solr.core.name
solr.core.configName
solr.core.schemaName
h3. Coding notes:
- DOMUtil.java:
cosmetic changes
toMapExcept systematically skips 'xml:base" attributes (which may come from
entity resolving)
- CoreDescriptor.java:
The core descriptor does not store properties as values but as expressions (and
all its members can be property expressions as well) allowing to write file as
defined (not as evaluated)
The public getCoreProperties is removed for that reason. (too bad we were in
such a rush...)
- CoreContainer.java:
changes related to extracting the core names before they are evaluated in load()
changes related to evaluating core descriptor member before adding them to the
core's loader properties
fix in persistFile which was not interpreting relative pathes correctly
fix in persist because properties were not written at the right place
changes in persist to write expressions (and core name when it is one)
- Config.java:
subsituteProperties has been moved out of constructor so calls must be explicit.
added the entity resolver
added subsituteIncludes which processes
- SolrConfig.java & IndexSchema.java
added explicit calls to substituteIncludesto perform property/include expansion
- SolrResourceLoader.java
cosmetic, changed getCoreProperties to getProperties (since they may come from
the CoreContainer)
- SolrProperties.java:
schema uses a localization (l10n) property to define an attribute
persists the file to check it keeps the expression properties
[jira] Issue Comment Edited: (SOLR-712) Support for relative path XML Entity Includes
[
https://issues.apache.org/jira/browse/SOLR-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625099#action_12625099
]
henrib edited comment on SOLR-712 at 8/23/08 12:33 PM:
--
Amit,
I reused your good idea in SOLR-646 and added an entity resolver so we can put
properties (variables) to get to the resource.
The crux of it is in Config.java ctor:
{code}
final SolrResourceLoader eloader = loader;
EntityResolver esolver = new EntityResolver() {
public InputSource resolveEntity(String publicId, String systemId) throws
SAXException, IOException {
if (systemId != null && systemId.startsWith("solr:")) {
String res = systemId.substring(5);
res = DOMUtil.substituteProperty(res, eloader.getProperties());
return new InputSource(eloader.openResource(res));
}
return null;
}
};
javax.xml.parsers.DocumentBuilder builder =
DocumentBuilderFactory.newInstance().newDocumentBuilder();
builder.setEntityResolver(esolver);
...
{code}
Oh, and I remove systematically xml:base form DOMUtil.toMapExcept
Thanks again.
was (Author: henrib):
Amit,
I reused your good idea and added an entity resolver so we can put properties
(variables) to get to the resource.
The crux of it is in Config.java ctor:
{code}
final SolrResourceLoader eloader = loader;
EntityResolver esolver = new EntityResolver() {
public InputSource resolveEntity(String publicId, String systemId) throws
SAXException, IOException {
if (systemId != null && systemId.startsWith("solr:")) {
String res = systemId.substring(5);
res = DOMUtil.substituteProperty(res, eloader.getProperties());
return new InputSource(eloader.openResource(res));
}
return null;
}
};
javax.xml.parsers.DocumentBuilder builder =
DocumentBuilderFactory.newInstance().newDocumentBuilder();
builder.setEntityResolver(esolver);
...
{code}
Oh, and I remove systematically xml:base form DOMUtil.toMapExcept
Thanks again.
> Support for relative path XML Entity Includes
> -
>
> Key: SOLR-712
> URL: https://issues.apache.org/jira/browse/SOLR-712
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 1.2, 1.3
>Reporter: Amit Nithian
>Priority: Minor
> Fix For: 1.2
>
> Attachments: XMLEntityInclude.tgz
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> This patch modifies the Config.java and IndexSchema.java to support XML
> entity includes of relative paths. When parsing an InputStream not providing
> a SystemID (i.e. base path for example) to the DOM parser will basically
> force all entity includes to be relative to the base project directory rather
> than the directory hosting the document. This patch simply passes in the
> configuration directory as the systemID thus making the entity includes
> relative to the home of solrconfig.xml and schema.xml.
> The IndexSchema.java was modified to ensure objects do NOT process the
> xml:base attribute. Newer Xerces-J parsers allow for the removal of this
> attribute in the DOM (by setting the appropriate feature); however, the DOM
> parser used by Java 5 doesn't support this feature.
> For example:
> Without the entity include, if my Solr app was running on C:\solr, then any
> entity includes would have to be relative to C:\solr regardless of
> solrconfig.xml and schema.xml. This patch allows for includes relative to the
> conf directory of solr.home (i.e. ../../my_base_schema.xml) would be located
> two directories above "conf".
> Please submit improvements or comments on this patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-712) Support for relative path XML Entity Includes
[
https://issues.apache.org/jira/browse/SOLR-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625099#action_12625099
]
Henri Biestro commented on SOLR-712:
Amit,
I reused your good idea and added an entity resolver so we can put properties
(variables) to get to the resource.
The crux of it is in Config.java ctor:
{code}
final SolrResourceLoader eloader = loader;
EntityResolver esolver = new EntityResolver() {
public InputSource resolveEntity(String publicId, String systemId) throws
SAXException, IOException {
if (systemId != null && systemId.startsWith("solr:")) {
String res = systemId.substring(5);
res = DOMUtil.substituteProperty(res, eloader.getProperties());
return new InputSource(eloader.openResource(res));
}
return null;
}
};
javax.xml.parsers.DocumentBuilder builder =
DocumentBuilderFactory.newInstance().newDocumentBuilder();
builder.setEntityResolver(esolver);
...
{code}
Oh, and I remove systematically xml:base form DOMUtil.toMapExcept
Thanks again.
> Support for relative path XML Entity Includes
> -
>
> Key: SOLR-712
> URL: https://issues.apache.org/jira/browse/SOLR-712
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 1.2, 1.3
>Reporter: Amit Nithian
>Priority: Minor
> Fix For: 1.2
>
> Attachments: XMLEntityInclude.tgz
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> This patch modifies the Config.java and IndexSchema.java to support XML
> entity includes of relative paths. When parsing an InputStream not providing
> a SystemID (i.e. base path for example) to the DOM parser will basically
> force all entity includes to be relative to the base project directory rather
> than the directory hosting the document. This patch simply passes in the
> configuration directory as the systemID thus making the entity includes
> relative to the home of solrconfig.xml and schema.xml.
> The IndexSchema.java was modified to ensure objects do NOT process the
> xml:base attribute. Newer Xerces-J parsers allow for the removal of this
> attribute in the DOM (by setting the appropriate feature); however, the DOM
> parser used by Java 5 doesn't support this feature.
> For example:
> Without the entity include, if my Solr app was running on C:\solr, then any
> entity includes would have to be relative to C:\solr regardless of
> solrconfig.xml and schema.xml. This patch allows for includes relative to the
> conf directory of solr.home (i.e. ../../my_base_schema.xml) would be located
> two directories above "conf".
> Please submit improvements or comments on this patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-646:
---
Attachment: solr-646.patch
Updated to be based on SOLR-716 commit. Thanks Shalin.
Some improvement over SOLR--716 :
- in solr.xml, /Solr/cores/core attributes can use properties defined in /solr
or system (including name/aliases)
- persistence of property expressions (rather than values)
- All core descriptor members can be expressions (related to SOLR-715 )
- fixes a bug in persistence related to SOLR-718 commit (will have to create an
issue for this)
- If a core was declared with an expression as its name and its aliases haven't
changed, persistence will rewrite the property expression.
That is, if you solr.xml does something like:
{code:xml}
...
...
{code}
The expression '${en-cores}' will be written back (if you did not realias the
core of course).
Some improvements over previous version:
There are now 2 ways to include files
One is a tribute to SOLR-712 (Thanks Amit) which means to include through
entities with the twist that an entity resolver exploit properties in URIs in
the 'solr:' protocol:
{code:xml}
]>
&textL10n;
...
{code}
Or the easier to read way (imho):
{code:xml}
...
{code}
There are tests for both versions.
Now, we've got options. :-)
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: solr-646.patch, solr-646.patch, solr-646.patch,
> SOLR-646.patch, solr-646.patch, solr-646.patch, solr-646.patch,
> solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in *solr.xml*.
> h3. Use cases:
> Describe core data directories from solr.xml as properties.
> Share the same schema and/or config file between multiple cores.
> Share reusable fragments of schema & configuration between multiple cores.
> h3. Usage:
> h4. solr.xml
> This *solr.xml* will be used to illustrates using properties for different
> purpose.
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> {{version}} : if you update your solr.xml or your cores for various motives,
> it can be useful to track of a version. In this example, this will be used to
> define the {{dataDir}} for each core.
> {{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive,
> it might be convenient to use a property that can then be used to describe
> the Solr core name.
> {{instanceDir}}: note that both cores will use the same instance directory,
> sharing their configuration and schema. The {{dataDir}} will be set for each
> of them from the *solrconfig.xml*.
> h4. solrconfig.xml
> This is where our *solr.xml* property are used to define the data directory
> as a composition of, in our example, the language code {{l10n}} and the core
> version stored in {{version}}.
> {code:xml}
>
> ${solr.solr.home}/data/${l10n}-${version}
>
>
> {code}
> h5. schema.xml
> The {{include}} allows to import a file within the schema (or a solrconfig);
> this can help de-clutter long schemas or reuse parts.
> {color:red}This is an experimental feature that may not be kept in the
> future.{color}
> The {{ctlField}} is just illustrating that a field & its type can be set
> through properties as well; in our example, we will want the 'english' core
> to refer to an 'english-configured' field and the 'french' core to a
> 'french-configured' one. The type for the field is defined as {{text-EN}} or
> {{text-FR}} after expansion.
> {code:xml}
>
>
> ...
>
>
>
> ...
>stored="true" multiValued="true" />
>
> {code}
> This schema is importing this *text-l10n.xml* file which is a *fragment*; the
> fragment tag must be present & indicates the file is to be included. Our
> example only defines different stopwords for each language but you could of
> course extend this to stemmers, synonyms, etc.
> {code:xml}
>
>positionIncrementGap="100">
> ...
>words="stopwords-fr.txt"/>
> ...
>
>positionIncrementGap="100">
> ...
>words="stopwords-en.txt"/>
> ...
>
>
> {code}
> h4. Technical specifications
> solr.xml can define properties at the multicore & each core level.
> Properti
[jira] Updated: (SOLR-716) Support properties in configuration files
[
https://issues.apache.org/jira/browse/SOLR-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-716:
---
Attachment: solr-716.patch
Might be post-commit but this will give a base to solr-646.
Fixed all issues raised by Shalin in previous version.
Added the persistence verification test. (thus the size bloat).
> Support properties in configuration files
> -
>
> Key: SOLR-716
> URL: https://issues.apache.org/jira/browse/SOLR-716
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-716.patch, SOLR-716.patch, solr-716.patch,
> SOLR-716.patch, SOLR-716.patch
>
>
> Initially suggested by Hoss at
> https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834
> and taken forward by Henri in SOLR-646
> # Allows users to define global as well as core-specific properties in
> solr.xml which can be used in solrconfig.xml and schema.xml
> {code:xml}
>
>
>
>
>
>
>
>
>
> {code}
> # The following core-specific properties will be added automatically:
> ** solr.core.instanceDir
> ** solr.core.name
> ** solr.core.configName
> ** solr.core.schemaName
> # The variable substitution will be done in this fall-back order --
> core-specific, implicit, global, system properties.
> # The properties defined in solr.xml should also be persisted back as is
> (without evaluation).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-716) Support properties in configuration files
[
https://issues.apache.org/jira/browse/SOLR-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625046#action_12625046
]
Henri Biestro commented on SOLR-716:
So I can define properties in a core scope based on properties defined in the
core-container scope.
Seems like a natural & expected feature.
Most of the code to allow idem-potent persistence allows it almost for free.
I did not expect that getting back all the solr-646 feature set (beside
include) with very little modifications to your code would re-create a problem.
Sorry, I wont interfere again.
> Support properties in configuration files
> -
>
> Key: SOLR-716
> URL: https://issues.apache.org/jira/browse/SOLR-716
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-716.patch, SOLR-716.patch, SOLR-716.patch
>
>
> Initially suggested by Hoss at
> https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834
> and taken forward by Henri in SOLR-646
> # Allows users to define global as well as core-specific properties in
> solr.xml which can be used in solrconfig.xml and schema.xml
> {code:xml}
>
>
>
>
>
>
>
>
>
> {code}
> # The following core-specific properties will be added automatically:
> ** solr.core.instanceDir
> ** solr.core.name
> ** solr.core.configName
> ** solr.core.schemaName
> # The variable substitution will be done in this fall-back order --
> core-specific, implicit, global, system properties.
> # The properties defined in solr.xml should also be persisted back as is
> (without evaluation).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-716) Support properties in configuration files
[
https://issues.apache.org/jira/browse/SOLR-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625040#action_12625040
]
henrib edited comment on SOLR-716 at 8/23/08 2:45 AM:
-
property expressions can be used in solr.xml & are preserved during solr.xml
persistence (solr-716.patch).
bq. If you were though, you'd need to keep the property expression map & the
property value map separated
CoreDescriptor members can be property expressions - thus a map of expressions
in both CoreDescriptor & CoreContainer to keep them around so we can reevaluate
& persist them.
.
substituteProperties is made explicit so we can choose when to run it (instead
of a ctor modification) and the substituteProperties() method would have been
necessary anyway in that case.
was (Author: henrib):
property expressions in solr.xml & preserved during solr.xml persistence.
CoreDescriptor members can be property expressions - thus a map of expressions
in both CoreDescriptor & CoreContainer.
substituteProperties is made explicit so we can choose when to run it (instead
of a ctor modification)
> Support properties in configuration files
> -
>
> Key: SOLR-716
> URL: https://issues.apache.org/jira/browse/SOLR-716
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-716.patch, SOLR-716.patch, SOLR-716.patch
>
>
> Initially suggested by Hoss at
> https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834
> and taken forward by Henri in SOLR-646
> # Allows users to define global as well as core-specific properties in
> solr.xml which can be used in solrconfig.xml and schema.xml
> {code:xml}
>
>
>
>
>
>
>
>
>
> {code}
> # The following core-specific properties will be added automatically:
> ** solr.core.instanceDir
> ** solr.core.name
> ** solr.core.configName
> ** solr.core.schemaName
> # The variable substitution will be done in this fall-back order --
> core-specific, implicit, global, system properties.
> # The properties defined in solr.xml should also be persisted back as is
> (without evaluation).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-716) Support properties in configuration files
[
https://issues.apache.org/jira/browse/SOLR-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-716:
---
Attachment: solr-716.patch
property expressions in solr.xml & preserved during solr.xml persistence.
CoreDescriptor members can be property expressions - thus a map of expressions
in both CoreDescriptor & CoreContainer.
substituteProperties is made explicit so we can choose when to run it (instead
of a ctor modification)
> Support properties in configuration files
> -
>
> Key: SOLR-716
> URL: https://issues.apache.org/jira/browse/SOLR-716
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-716.patch, SOLR-716.patch, SOLR-716.patch
>
>
> Initially suggested by Hoss at
> https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834
> and taken forward by Henri in SOLR-646
> # Allows users to define global as well as core-specific properties in
> solr.xml which can be used in solrconfig.xml and schema.xml
> {code:xml}
>
>
>
>
>
>
>
>
>
> {code}
> # The following core-specific properties will be added automatically:
> ** solr.core.instanceDir
> ** solr.core.name
> ** solr.core.configName
> ** solr.core.schemaName
> # The variable substitution will be done in this fall-back order --
> core-specific, implicit, global, system properties.
> # The properties defined in solr.xml should also be persisted back as is
> (without evaluation).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-716) Support properties in configuration files
[
https://issues.apache.org/jira/browse/SOLR-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625028#action_12625028
]
henrib edited comment on SOLR-716 at 8/23/08 12:22 AM:
--
bq.SolrResourceLoader keeps a reference to the CoreDescriptor
It would seem preferable & possible to only store the properties (versus the
CoreDescriptor) in the SolrResourceLoader; this is the only piece needed for
evaluation.
IMHO, the CoreDescriptor giving potential access to everything (through the
CoreContainer), it should not be shared/stored outside of the SolrCore without
careful impact consideration.
bq. users cannot specify a variable inside solr.xml
You could do a second evaluation pass to expand the property values (if they
are property expressions) created for the CoreContainer and for each
CoreDescriptor.
If you were though, you'd need to keep the property expression map & the
property value map separated.
was (Author: henrib):
Setting aside the potential debate of using regexp to solve a DOM related
problem... :-)
bq.SolrResourceLoader keeps a reference to the CoreDescriptor
It would seem preferable & possible to only store the properties (versus the
CoreDescriptor) in the SolrResourceLoader; this is the only piece needed for
evaluation.
IMHO, the CoreDescriptor giving potential access to everything (through the
CoreContainer), it should not be shared/stored outside of the SolrCore without
careful impact consideration.
bq. users cannot specify a variable inside solr.xml
You could do a second evaluation pass to expand the property values (if they
are property expressions) created for the CoreContainer and for each
CoreDescriptor.
If you were though, you'd need to keep the property expression map & the
property value map separated.
> Support properties in configuration files
> -
>
> Key: SOLR-716
> URL: https://issues.apache.org/jira/browse/SOLR-716
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: SOLR-716.patch
>
>
> Initially suggested by Hoss at
> https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834
> and taken forward by Henri in SOLR-646
> # Allows users to define global as well as core-specific properties in
> solr.xml which can be used in solrconfig.xml and schema.xml
> {code:xml}
>
>
>
>
>
>
>
>
>
> {code}
> # The following core-specific properties will be added automatically:
> ** solr.core.instanceDir
> ** solr.core.name
> ** solr.core.configName
> ** solr.core.schemaName
> # The variable substitution will be done in this fall-back order --
> core-specific, implicit, global, system properties.
> # The properties defined in solr.xml should also be persisted back as is
> (without evaluation).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-716) Support properties in configuration files
[
https://issues.apache.org/jira/browse/SOLR-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625028#action_12625028
]
henrib edited comment on SOLR-716 at 8/23/08 12:19 AM:
--
Setting aside the potential debate of using regexp to solve a DOM related
problem... :-)
bq.SolrResourceLoader keeps a reference to the CoreDescriptor
It would seem preferable & possible to only store the properties (versus the
CoreDescriptor) in the SolrResourceLoader; this is the only piece needed for
evaluation.
IMHO, the CoreDescriptor giving potential access to everything (through the
CoreContainer), it should not be shared/stored outside of the SolrCore without
careful impact consideration.
bq. users cannot specify a variable inside solr.xml
You could do a second evaluation pass to expand the property values (if they
are property expressions) created for the CoreContainer and for each
CoreDescriptor.
If you were though, you'd need to keep the property expression map & the
property value map separated.
was (Author: henrib):
bq.SolrResourceLoader keeps a reference to the CoreDescriptor
It would seem preferable & possible to only store the properties (versus the
CoreDescriptor) in the SolrResourceLoader; this is the only piece needed for
evaluation.
IMHO, the CoreDescriptor giving potential access to everything (through the
CoreContainer), it should not be shared/stored outside of the SolrCore without
careful impact consideration.
bq. users cannot specify a variable inside solr.xml
You could do a second evaluation pass to expand the property values (if they
are property expressions) created for the CoreContainer and for each
CoreDescriptor.
If you were though, you'd need to keep the property expression map & the
property value map separated.
> Support properties in configuration files
> -
>
> Key: SOLR-716
> URL: https://issues.apache.org/jira/browse/SOLR-716
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: SOLR-716.patch
>
>
> Initially suggested by Hoss at
> https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834
> and taken forward by Henri in SOLR-646
> # Allows users to define global as well as core-specific properties in
> solr.xml which can be used in solrconfig.xml and schema.xml
> {code:xml}
>
>
>
>
>
>
>
>
>
> {code}
> # The following core-specific properties will be added automatically:
> ** solr.core.instanceDir
> ** solr.core.name
> ** solr.core.configName
> ** solr.core.schemaName
> # The variable substitution will be done in this fall-back order --
> core-specific, implicit, global, system properties.
> # The properties defined in solr.xml should also be persisted back as is
> (without evaluation).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-716) Support properties in configuration files
[
https://issues.apache.org/jira/browse/SOLR-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625028#action_12625028
]
Henri Biestro commented on SOLR-716:
bq.SolrResourceLoader keeps a reference to the CoreDescriptor
It would seem preferable & possible to only store the properties (versus the
CoreDescriptor) in the SolrResourceLoader; this is the only piece needed for
evaluation.
IMHO, the CoreDescriptor giving potential access to everything (through the
CoreContainer), it should not be shared/stored outside of the SolrCore without
careful impact consideration.
bq. users cannot specify a variable inside solr.xml
You could do a second evaluation pass to expand the property values (if they
are property expressions) created for the CoreContainer and for each
CoreDescriptor.
If you were though, you'd need to keep the property expression map & the
property value map separated.
> Support properties in configuration files
> -
>
> Key: SOLR-716
> URL: https://issues.apache.org/jira/browse/SOLR-716
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: SOLR-716.patch
>
>
> Initially suggested by Hoss at
> https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834
> and taken forward by Henri in SOLR-646
> # Allows users to define global as well as core-specific properties in
> solr.xml which can be used in solrconfig.xml and schema.xml
> {code:xml}
>
>
>
>
>
>
>
>
>
> {code}
> # The following core-specific properties will be added automatically:
> ** solr.core.instanceDir
> ** solr.core.name
> ** solr.core.configName
> ** solr.core.schemaName
> # The variable substitution will be done in this fall-back order --
> core-specific, implicit, global, system properties.
> # The properties defined in solr.xml should also be persisted back as is
> (without evaluation).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-715) CoreDescriptor should fully describe what is necessary to create/re-create a SolrCore
CoreDescriptor should fully describe what is necessary to create/re-create a SolrCore - Key: SOLR-715 URL: https://issues.apache.org/jira/browse/SOLR-715 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Reporter: Henri Biestro Priority: Minor Before core 'aliasing' was introduced, the following were true: There is one CoreDescriptor per SolCore The SolrDescriptor fully describes the data needed to create/re-create a SolrCore. The CoreDescriptor does not fully describe the data needed to create/re-create a SolrCore since only the 'name' (aka the 1st alias) is used in the CoreDescirptor constructor.. It is then not possible anymore to create dynamically a SolrCore with multiple aliases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-714) CoreContainer.Load does not handle correctly multiple aliases
CoreContainer.Load does not handle correctly multiple aliases
-
Key: SOLR-714
URL: https://issues.apache.org/jira/browse/SOLR-714
Project: Solr
Issue Type: Bug
Affects Versions: 1.3
Reporter: Henri Biestro
There is a typo that prevent from correctly loading multiple aliases in
CoreContainer.Load:203
{code}
for (int a=1; a
[jira] Commented: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624813#action_12624813
]
Henri Biestro commented on SOLR-646:
Given that:
1 - I've wasted too much time of too many people with a feature & code that's
too complex/wide
2 - The time & added delay it will take for me to create the sub-issues (for
the 2 bugs in CoreContainer, 1 bug & 1 rfe for persistence), modify this issue
description & examples and create the code (although I'm not sure that's needed
or a desirable)
3 - There is an alternate patch code ready that a committer has written that
he's comfortable with that solves the property expansion problem and he has
been kind enough not to commit it already
Let's use the efficient route:
1 - Push this solr-646 issue to a 'future release' date so it can be revisited
if ever needed or at least serve as an example of "things to not do when you
contribute"
2 - Create a new issue for 1.3 that is solved by the alternative patch, commit
it, close the issue & release 1.3
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-646.patch, solr-646.patch, SOLR-646.patch,
> solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in *solr.xml*.
> h3. Use cases:
> Describe core data directories from solr.xml as properties.
> Share the same schema and/or config file between multiple cores.
> Share reusable fragments of schema & configuration between multiple cores.
> h3. Usage:
> h4. solr.xml
> This *solr.xml* will be used to illustrates using properties for different
> purpose.
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> {{version}} : if you update your solr.xml or your cores for various motives,
> it can be useful to track of a version. In this example, this will be used to
> define the {{dataDir}} for each core.
> {{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive,
> it might be convenient to use a property that can then be used to describe
> the Solr core name.
> {{instanceDir}}: note that both cores will use the same instance directory,
> sharing their configuration and schema. The {{dataDir}} will be set for each
> of them from the *solrconfig.xml*.
> h4. solrconfig.xml
> This is where our *solr.xml* property are used to define the data directory
> as a composition of, in our example, the language code {{l10n}} and the core
> version stored in {{version}}.
> {code:xml}
>
> ${solr.solr.home}/data/${l10n}-${version}
>
>
> {code}
> h5. schema.xml
> The {{include}} allows to import a file within the schema (or a solrconfig);
> this can help de-clutter long schemas or reuse parts.
> {color:red}This is an experimental feature that may not be kept in the
> future.{color}
> The {{ctlField}} is just illustrating that a field & its type can be set
> through properties as well; in our example, we will want the 'english' core
> to refer to an 'english-configured' field and the 'french' core to a
> 'french-configured' one. The type for the field is defined as {{text-EN}} or
> {{text-FR}} after expansion.
> {code:xml}
>
>
> ...
>
>
>
> ...
>stored="true" multiValued="true" />
>
> {code}
> This schema is importing this *text-l10n.xml* file which is a *fragment*; the
> fragment tag must be present & indicates the file is to be included. Our
> example only defines different stopwords for each language but you could of
> course extend this to stemmers, synonyms, etc.
> {code:xml}
>
>positionIncrementGap="100">
> ...
>words="stopwords-fr.txt"/>
> ...
>
>positionIncrementGap="100">
> ...
>words="stopwords-en.txt"/>
> ...
>
>
> {code}
> h4. Technical specifications
> solr.xml can define properties at the multicore & each core level.
> Properties defined in the multicore scope can override system properties.
> Properties defined in a core scope can override multicore & system properties.
> Property definitions can use expressions to define their name & value; these
> expressions are evaluated in their outer scope context .
> CoreContainer serialization keeps prop
[jira] Issue Comment Edited: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624485#action_12624485
]
henrib edited comment on SOLR-646 at 8/21/08 2:40 PM:
-
Modified property definition syntax to follow ant's.
Renamed test class.
Made the include an experimental feature.
was (Author: henrib):
Modified property definition syntax to follow ant's.
Renamed test class.
Made the include an experimental feature.
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-646.patch, solr-646.patch, SOLR-646.patch,
> solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in *solr.xml*.
> h3. Use cases:
> Describe core data directories from solr.xml as properties.
> Share the same schema and/or config file between multiple cores.
> Share reusable fragments of schema & configuration between multiple cores.
> h3. Usage:
> h4. solr.xml
> This *solr.xml* will be used to illustrates using properties for different
> purpose.
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> {{version}} : if you update your solr.xml or your cores for various motives,
> it can be useful to track of a version. In this example, this will be used to
> define the {{dataDir}} for each core.
> {{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive,
> it might be convenient to use a property that can then be used to describe
> the Solr core name.
> {{instanceDir}}: note that both cores will use the same instance directory,
> sharing their configuration and schema. The {{dataDir}} will be set for each
> of them from the *solrconfig.xml*.
> h4. solrconfig.xml
> This is where our *solr.xml* property are used to define the data directory
> as a composition of, in our example, the language code {{l10n}} and the core
> version stored in {{version}}.
> {code:xml}
>
> ${solr.solr.home}/data/${l10n}-${version}
>
>
> {code}
> h5. schema.xml
> The {{include}} allows to import a file within the schema (or a solrconfig);
> this can help de-clutter long schemas or reuse parts.
> {color:red}This is an experimental feature that may not be kept in the
> future.{color}
> The {{ctlField}} is just illustrating that a field & its type can be set
> through properties as well; in our example, we will want the 'english' core
> to refer to an 'english-configured' field and the 'french' core to a
> 'french-configured' one. The type for the field is defined as {{text-EN}} or
> {{text-FR}} after expansion.
> {code:xml}
>
>
> ...
>
>
>
> ...
>stored="true" multiValued="true" />
>
> {code}
> This schema is importing this *text-l10n.xml* file which is a *fragment*; the
> fragment tag must be present & indicates the file is to be included. Our
> example only defines different stopwords for each language but you could of
> course extend this to stemmers, synonyms, etc.
> {code:xml}
>
>positionIncrementGap="100">
> ...
>words="stopwords-fr.txt"/>
> ...
>
>positionIncrementGap="100">
> ...
>words="stopwords-en.txt"/>
> ...
>
>
> {code}
> h4. Technical specifications
> solr.xml can define properties at the multicore & each core level.
> Properties defined in the multicore scope can override system properties.
> Properties defined in a core scope can override multicore & system properties.
> Property definitions can use expressions to define their name & value; these
> expressions are evaluated in their outer scope context .
> CoreContainer serialization keeps properties as defined; persistence is
> idem-potent. (ie property expressions are written, not their evaluation).
> The core descriptor properties are automatically defined in each core
> context, namely:
> solr.core.instanceDir
> solr.core.name
> solr.core.configName
> solr.core.schemaName
> h3. Coding notes:
> - DOMUtil.java:
> refactored substituteSystemProperties to use an Evaluator;
> an Evaluator is a DOM visitor that expands property expressions "in place"
> using a property map as an evaluation context
> added an asString(node) method for logging purpose
>
[jira] Updated: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-646:
---
Description:
This patch refers to 'generalized configuration properties' as specified by
[HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
This means configuration & schema files can use expression based on properties
defined in *solr.xml*.
h3. Use cases:
Describe core data directories from solr.xml as properties.
Share the same schema and/or config file between multiple cores.
Share reusable fragments of schema & configuration between multiple cores.
h3. Usage:
h4. solr.xml
This *solr.xml* will be used to illustrates using properties for different
purpose.
{code:xml}
{code}
{{version}} : if you update your solr.xml or your cores for various motives, it
can be useful to track of a version. In this example, this will be used to
define the {{dataDir}} for each core.
{{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive, it
might be convenient to use a property that can then be used to describe the
Solr core name.
{{instanceDir}}: note that both cores will use the same instance directory,
sharing their configuration and schema. The {{dataDir}} will be set for each of
them from the *solrconfig.xml*.
h4. solrconfig.xml
This is where our *solr.xml* property are used to define the data directory as
a composition of, in our example, the language code {{l10n}} and the core
version stored in {{version}}.
{code:xml}
${solr.solr.home}/data/${l10n}-${version}
{code}
h5. schema.xml
The {{include}} allows to import a file within the schema (or a solrconfig);
this can help de-clutter long schemas or reuse parts.
{color:red}This is an experimental feature that may not be kept in the
future.{color}
The {{ctlField}} is just illustrating that a field & its type can be set
through properties as well; in our example, we will want the 'english' core to
refer to an 'english-configured' field and the 'french' core to a
'french-configured' one. The type for the field is defined as {{text-EN}} or
{{text-FR}} after expansion.
{code:xml}
...
...
{code}
This schema is importing this *text-l10n.xml* file which is a *fragment*; the
fragment tag must be present & indicates the file is to be included. Our
example only defines different stopwords for each language but you could of
course extend this to stemmers, synonyms, etc.
{code:xml}
...
...
...
...
{code}
h4. Technical specifications
solr.xml can define properties at the multicore & each core level.
Properties defined in the multicore scope can override system properties.
Properties defined in a core scope can override multicore & system properties.
Property definitions can use expressions to define their name & value; these
expressions are evaluated in their outer scope context .
CoreContainer serialization keeps properties as defined; persistence is
idem-potent. (ie property expressions are written, not their evaluation).
The core descriptor properties are automatically defined in each core context,
namely:
solr.core.instanceDir
solr.core.name
solr.core.configName
solr.core.schemaName
h3. Coding notes:
- DOMUtil.java:
refactored substituteSystemProperties to use an Evaluator;
an Evaluator is a DOM visitor that expands property expressions "in place"
using a property map as an evaluation context
added an asString(node) method for logging purpose
- CoreDescriptor.java:
added an expression member to keep property expressions as defined in solr.xml
for persistence - allowing to write file as defined (not as expanded)
- CoreContainer.java:
add an expression member to keep property expression as defined in solr.xml for
persistence - allowing to write file as defined (not as expanded);
solrx.xml peristence is idem-potent
added a local DOMUtil.Evaluator that tracks property expressions to evaluate &
store them
*issues outlined through solr-646:*
fix in load:
CoreDescriptor p = new CoreDescriptor(this, names, );
was: CoreDescriptor p = new CoreDescriptor(this, name, ...);
fix in load;
register(aliases.get(a), core, false);
was of register(aliases.get(i), core, false);
- CoreAdminHandler.java
added an optional fileName to persist so it is possible to write the solr.xml
to a different file (for comparison purpose)
- CoreAdminRequest.java
added PersistRequest to allow passing optional fileName
- Config.java:
subsituteProperties has been moved out of constructor & doc member made
protected to allow override
added an IncludesEvaluator that deals with include/fragment
- SolrConfig.java & IndexSchema.ava
added explicit calls to substituteProperties to pe
[jira] Updated: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-646:
---
Description:
This patch refers to 'generalized configuration properties' as specified by
[HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
This means configuration & schema files can use expression based on properties
defined in *solr.xml*.
h3. Use cases:
Describe core data directories from solr.xml as properties.
Share the same schema and/or config file between multiple cores.
Share reusable fragments of schema & configuration between multiple cores.
h3. Usage:
h4. solr.xml
This *solr.xml* will be used to illustrates using properties for different
purpose.
{code:xml}
{code}
{{version}} : if you update your solr.xml or your cores for various motives, it
can be useful to track of a version. In this example, this will be used to
define the {{dataDir}} for each core.
{{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive, it
might be convenient to use a property that can then be used to describe the
Solr core name.
{{instanceDir}}: note that both cores will use the same instance directory,
sharing their configuration and schema. The {{dataDir}} will be set for each of
them from the *solrconfig.xml*.
h4. solrconfig.xml
This is where our *solr.xml* property are used to define the data directory as
a composition of, in our example, the language code {{l10n}} and the core
version stored in {{version}}.
{code:xml}
${solr.solr.home}/data/${l10n}-${version}
{code}
h5. schema.xml
The {{include}} allows to import a file within the schema (or a solrconfig);
this can help de-clutter long schemas or reuse parts.
{color:red}This is an experimental feature thant may not be kept in the
future.{color}
The {{ctlField}} is just illustrating that a field & its type can be set
through properties as well; in our example, we will want the 'english' core to
refer to an 'english-configured' field and the 'french' core to a
'french-configured' one. The type for the field is defined as {{text-EN}} or
{{text-FR}} after expansion.
{code:xml}
...
...
{code}
This schema is importing this *text-l10n.xml* file which is a *fragment*; the
fragment tag must be present & indicates the file is to be included. Our
example only defines different stopwords for each language but you could of
course extend this to stemmers, synonyms, etc.
{code:xml}
...
...
...
...
{code}
h4. Technical specifications
solr.xml can define properties at the multicore & each core level.
Properties defined in the multicore scope can override system properties.
Properties defined in a core scope can override multicore & system properties.
Property definitions can use expressions to define their name & value; these
expressions are evaluated in their outer scope context .
CoreContainer serialization keeps properties as defined; persistence is
idem-potent. (ie property expressions are written, not their evaluation).
The core descriptor properties are automatically defined in each core context,
namely:
solr.core.instanceDir
solr.core.name
solr.core.configName
solr.core.schemaName
h3. Coding notes:
- DOMUtil.java:
refactored substituteSystemProperties to use an Evaluator;
an Evaluator is a DOM visitor that expands property expressions "in place"
using a property map as an evaluation context
added an asString(node) method for logging purpose
- CoreDescriptor.java:
added an expression member to keep property expressions as defined in solr.xml
for persistence - allowing to write file as defined (not as expanded)
- CoreContainer.java:
add an expression member to keep property expression as defined in solr.xml for
persistence - allowing to write file as defined (not as expanded);
solrx.xml peristence is idem-potent
added a local DOMUtil.Evaluator that tracks property expressions to evaluate &
store them
*issues outlined through solr-646:*
fix in load:
CoreDescriptor p = new CoreDescriptor(this, names, );
was: CoreDescriptor p = new CoreDescriptor(this, name, ...);
fix in load;
register(aliases.get(a), core, false);
was of register(aliases.get(i), core, false);
- CoreAdminHandler.java
added an optional fileName to persist so it is possible to write the solr.xml
to a different file (for comparison purpose)
- CoreAdminRequest.java
added PersistRequest to allow passing optional fileName
- Config.java:
subsituteProperties has been moved out of constructor & doc member made
protected to allow override
added an IncludesEvaluator that deals with include/fragment
- SolrConfig.java & IndexSchema.ava
added explicit calls to substituteProperties to p
[jira] Updated: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-646:
---
Attachment: solr-646.patch
Modified property definition syntax to follow ant's.
Renamed test class.
Made the include an experimental feature.
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-646.patch, solr-646.patch, SOLR-646.patch,
> solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in *solr.xml*.
> h3. Use cases:
> Describe core data directories from solr.xml as properties.
> Share the same schema and/or config file between multiple cores.
> Share reusable fragments of schema & configuration between multiple cores.
> h3. Usage:
> h4. solr.xml
> This *solr.xml* will be used to illustrates using properties for different
> purpose.
> {code:xml}
>
> 1.3
> english, french
> en,core0
> fr,core1
>
>
> 3.5
> EN
> core0
> This is a sample
>
>
> 2.4
> FR
> core1
> Ceci est un exemple
>
>
>
> {code}
> {{version}} : if you update your solr.xml or your cores for various motives,
> it can be useful to track of a version. In this example, this will be used to
> define the {{dataDir}} for each core.
> {{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive,
> it might be convenient to use a property that can then be used to describe
> the Solr core name.
> {{instanceDir}}: note that both cores will use the same instance directory,
> sharing their configuration and schema. The {{dataDir}} will be set for each
> of them from the *solrconfig.xml*.
> h4. solrconfig.xml
> This is where our *solr.xml* property are used to define the data directory
> as a composition of, in our example, the language code {{l10n}} and the core
> version stored in {{version}}.
> {code:xml}
>
> ${solr.solr.home}/data/${l10n}-${version}
>
>
> {code}
> h5. schema.xml
> The {{include}} allows to import a file within the schema (or a solrconfig);
> this can help de-clutter long schemas.
> The {{ctlField}} is just illustrating that a field & its type can be set
> through properties as well; in our example, we will want the 'english' core
> to refer to an 'english-configured' field and the 'french' core to a
> 'french-configured' one. The type for the field is defined as {{text-EN}} or
> {{text-FR}} after expansion.
> {code:xml}
>
>
> ...
>
>
>
> ...
>stored="true" multiValued="true" />
>
> {code}
> This schema is importing this *text-l10n.xml* file which is a *fragment*; the
> fragment tag must be present & indicates the file is to be included. Our
> example only defines different stopwords for each language but you could of
> course extend this to stemmers, synonyms, etc.
> {code:xml}
>
>positionIncrementGap="100">
> ...
>words="stopwords-fr.txt"/>
> ...
>
>positionIncrementGap="100">
> ...
>words="stopwords-en.txt"/>
> ...
>
>
> {code}
> h4. Technical specifications
> solr.xml can define properties at the multicore & each core level.
> Properties defined in the multicore scope can override system properties.
> Properties defined in a core scope can override multicore & system properties.
> Property definitions can use expressions to define their name & value; these
> expressions are evaluated in their outer scope context .
> CoreContainer serialization keeps properties as defined; persistence is
> idem-potent. (ie property expressions are written, not their evaluation).
> The core descriptor properties are automatically defined in each core
> context, namely:
> solr.core.instanceDir
> solr.core.name
> solr.core.configName
> solr.core.schemaName
> h3. Coding notes:
> - DOMUtil.java:
> refactored substituteSystemProperties to use an Evaluator;
> an Evaluator is a DOM visitor that expands property expressions "in place"
> using a property map as an evaluation context
> added an asString(node) method for logging purpose
> - CoreDescriptor.java:
> added an expression member to keep property expressions as defined in
> solr.xml for persistence - allowing to write file as defined (not as expanded)
> - CoreContainer.java:
> add an expression member to keep property ex
[jira] Issue Comment Edited: (SOLR-646) Configuration properties in multicore.xml
[ https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624467#action_12624467 ] henrib edited comment on SOLR-646 at 8/21/08 2:06 PM: - 0 - I *do* use today an include mechanism of some sort so my field types are not defined in the schema; this allows to automate the schema generation from another tool & not have to deal with copying content. 1 - the CoreContainer evaluator is a "transient" being; it keeps track of properties as they are "read" and how they are evaluated during configuration. It is not stored nor kept beyond the scope of load(). I dont see what you mean by house keeping. The things we keep afterwards are property expressions (1 map in CoreContainer & 1 map per CoreDescriptor) and 1 Properties instance per SolrResourceLoader. 2 - The CoreContainer Evaluator is the part that declares properties, assign them a scope, etc. The code is fairly well commented so I dont really get your comment. Anyway, it is necessary, for persistence to be idempotent, ie we should be able to write what we (just) read as in SolrProperties test, we need to keep these around. The Config evaluator is dealing with the include so I wont get there; what about the idea of an "experimental" state? 3 - To keep the evaluator so we can extract the pieces of information it collected (cf 1). The loaderProperties are filled in by the evaluator as the last step of its subsituteProperties method. We have to do it at the end so the original evaluation scope is preserved during the whole evaluation. 4 - You misinterpret my example; when I'm changing some indexing/schema configuration in an heavy way, I like to be able to test it before, etc; these changes (like changing stemmer, synonyms, etc) require reindexing. So, the version I'm talking about is the 'index data' version. To be strict, I do consider modifyng the schema a "major" version and modifying config a "minor" one wrt to index reindex/reload. But that would make the example a bit terse. 5 - I believe I did not remove any public method in the patch, did I? 6 - The visitor pattern used in the original substituteSystemProperties has just been 'methodified'. The code is no different than what it was and it allows to implement just what's needed by derivation. was (Author: henrib): 0 - I *do* use today an include mechanism of some sort so my field types are not defined in the schema; this allows to automate the schema generation from another tool & not have to deal with copying content. 1 - the CoreContainer evaluator is a "transient" being; it keeps track of properties as they are "read" and how they are evaluated during configuration. It is not stored nor kept beyond the scope of load(). I dont see what you mean by house keeping. The things we keep afterwards are property expressions (1 map in CoreContainer & 1 map per core) and 1 Properties instance per CoreContainer & per map. 2 - The CoreContainer Evaluator is the part that declares properties, assign them a scope, etc. The code is fairly well commented so I dont really get your comment. Anyway, it is necessary, for persistence to be idempotent, ie we should be able to write what we (just) read as in SolrProperties test, we need to keep these around. The Config evaluator is dealing with the include so I wont get there; what about the idea of an "experimental" state? 3 - To keep the evaluator so we can extract the pieces of information it collected (cf 1). The loaderProperties are filled in by the evaluator as the last step of its subsituteProperties method. We have to do it at the end so the original evaluation scope is preserved during the whole evaluation. 4 - You misinterpret my example; when I'm changing some indexing/schema configuration in an heavy way, I like to be able to test it before, etc; these changes (like changing stemmer, synonyms, etc) require reindexing. So, the version I'm talking about is the 'index data' version. To be strict, I do consider modifyng the schema a "major" version and modifying config a "minor" one wrt to index reindex/reload. But that would make the example a bit terse. 5 - I believe I did not remove any public method in the patch, did I? 6 - The visitor pattern used in the original substituteSystemProperties has just been 'methodified'. The code is no different than what it was and it allows to implement just what's needed by derivation. > Configuration properties in multicore.xml > - > > Key: SOLR-646 > URL: https://issues.apache.org/jira/browse/SOLR-646 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Henri Biestro >Assignee: Shalin Shekhar Mangar > Fix For: 1.3 > > Attachments: solr-646.pa
[jira] Issue Comment Edited: (SOLR-646) Configuration properties in multicore.xml
[ https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624467#action_12624467 ] henrib edited comment on SOLR-646 at 8/21/08 1:18 PM: - 0 - I *do* use today an include mechanism of some sort so my field types are not defined in the schema; this allows to automate the schema generation from another tool & not have to deal with copying content. 1 - the CoreContainer evaluator is a "transient" being; it keeps track of properties as they are "read" and how they are evaluated during configuration. It is not stored nor kept beyond the scope of load(). I dont see what you mean by house keeping. The things we keep afterwards are property expressions (1 map in CoreContainer & 1 map per core) and 1 Properties instance per CoreContainer & per map. 2 - The CoreContainer Evaluator is the part that declares properties, assign them a scope, etc. The code is fairly well commented so I dont really get your comment. Anyway, it is necessary, for persistence to be idempotent, ie we should be able to write what we (just) read as in SolrProperties test, we need to keep these around. The Config evaluator is dealing with the include so I wont get there; what about the idea of an "experimental" state? 3 - To keep the evaluator so we can extract the pieces of information it collected (cf 1). The loaderProperties are filled in by the evaluator as the last step of its subsituteProperties method. We have to do it at the end so the original evaluation scope is preserved during the whole evaluation. 4 - You misinterpret my example; when I'm changing some indexing/schema configuration in an heavy way, I like to be able to test it before, etc; these changes (like changing stemmer, synonyms, etc) require reindexing. So, the version I'm talking about is the 'index data' version. To be strict, I do consider modifyng the schema a "major" version and modifying config a "minor" one wrt to index reindex/reload. But that would make the example a bit terse. 5 - I believe I did not remove any public method in the patch, did I? 6 - The visitor pattern used in the original substituteSystemProperties has just been 'methodified'. The code is no different than what it was and it allows to implement just what's needed by derivation. was (Author: henrib): 0 - I *do* use today an include mechanism of some sort so my field types are not defined in the schema; this allows to automate the schema generation from another tool & not have to deal with copying content. 1 - the CoreContainer evaluator is a "transient" being; it keeps track of properties as they are "read" and how they are evaluated during configuration. It is not stored nor kept beyond the scope of load(). I dont see what you mean by house keeping. The things we keep afterwards are property expressions (1 map in CoreContainer & 1 map per core) and 1 Properties instance per CoreContainer & per map. 2 - The CoreContainer Evaluator is the part that declares properties, assign them a scope, etc. The code is fairly well commented so I dont really get your comment. Anyway, it is necessary, for persistence to be idempotent, ie we should be able to write what we (just) read as in SolrProperties test, we need to keep these around. The Config evaluator is dealing with the include so I wont get there since ... 3 - To keep the evaluator so we can extract the pieces of information it collected (cf 1). The loaderProperties are filled in by the evaluator as the last step of its subsituteProperties method. We have to do it at the end so the original evaluation scope is preserved during the whole evaluation. 4 - You misinterpret my example; when I'm changing some indexing/schema configuration in an heavy way, I like to be able to test it before, etc; these changes (like changing stemmer, synonyms, etc) require reindexing. So, the version I'm talking about is the 'index data' version. To be strict, I do consider modifyng the schema a "major" version and modifying config a "minor" one wrt to index reindex/reload. But that would make the example a bit terse. 5 - I believe I did not remove any public method in the patch, did I? 6 - The visitor pattern used in the original substituteSystemProperties has just been 'methodified'. The code is no different than what it was and it allows to implement just what's needed by derivation. > Configuration properties in multicore.xml > - > > Key: SOLR-646 > URL: https://issues.apache.org/jira/browse/SOLR-646 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Henri Biestro >Assignee: Shalin Shekhar Mangar > Fix For: 1.3 > > Attachments: solr-646.patch, SOLR-646.patch, solr-646.patch, > solr-
[jira] Issue Comment Edited: (SOLR-646) Configuration properties in multicore.xml
[ https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624467#action_12624467 ] henrib edited comment on SOLR-646 at 8/21/08 1:15 PM: - 0 - I *do* use today an include mechanism of some sort so my field types are not defined in the schema; this allows to automate the schema generation from another tool & not have to deal with copying content. 1 - the CoreContainer evaluator is a "transient" being; it keeps track of properties as they are "read" and how they are evaluated during configuration. It is not stored nor kept beyond the scope of load(). I dont see what you mean by house keeping. The things we keep afterwards are property expressions (1 map in CoreContainer & 1 map per core) and 1 Properties instance per CoreContainer & per map. 2 - The CoreContainer Evaluator is the part that declares properties, assign them a scope, etc. The code is fairly well commented so I dont really get your comment. Anyway, it is necessary, for persistence to be idempotent, ie we should be able to write what we (just) read as in SolrProperties test, we need to keep these around. The Config evaluator is dealing with the include so I wont get there since ... 3 - To keep the evaluator so we can extract the pieces of information it collected (cf 1). The loaderProperties are filled in by the evaluator as the last step of its subsituteProperties method. We have to do it at the end so the original evaluation scope is preserved during the whole evaluation. 4 - You misinterpret my example; when I'm changing some indexing/schema configuration in an heavy way, I like to be able to test it before, etc; these changes (like changing stemmer, synonyms, etc) require reindexing. So, the version I'm talking about is the 'index data' version. To be strict, I do consider modifyng the schema a "major" version and modifying config a "minor" one wrt to index reindex/reload. But that would make the example a bit terse. 5 - I believe I did not remove any public method in the patch, did I? 6 - The visitor pattern used in the original substituteSystemProperties has just been 'methodified'. The code is no different than what it was and it allows to implement just what's needed by derivation. was (Author: henrib): 0 - I *do* use today an include mechanism of some sort so my field types are not defined in the schema; this allows to automate the schema generation from another tool & not have to deal with copying content. 1 - the CoreContainer evaluator is a "transient" being; it keeps track of properties as they are "read" and how they are evaluated during configuration. It is not stored nor kept beyond the scope of load(). I dont see what you mean by house keeping. The things we keep afterwards are property expressions (1 map in CoreContainer & 1 map per core) and 1 Properties instance per CoreContainer & per map. 2 - The CoreContainer Evaluator is the part that declares properties, assign them a scope, etc. The code is fairly well commented so I dont really get your comment. Anyway, it is necessary, for persistence to be idempotent, ie we should be able to write what we (just) read as in SolrProperties test, we need to keep these around. The Config evaluator is dealing with the include so I wont get there since ... 3 - To keep the evaluator so we can extract the pieces of information it collected (cf 1). The loaderProperties are filled in by the evaluator as the last step of its subsituteProperties method. We have to do it at the end so the original evaluation scope is preserved during the whole evaluation. 4 - You misinterpret my example; when I'm changing some indexing/schema configuration in an heavy way, I like to be able to test it before, etc; these changes (like changing stemmer, synonyms, etc) require reindexing. So, the version I'm talking about is the 'index data' version. 5 - I believe I did not remove any public method in the patch, did I? 6 - The visitor pattern used in the original substituteSystemProperties has just been 'methodified'. The code is no different than what it was and it allows to implement just what's needed by derivation. > Configuration properties in multicore.xml > - > > Key: SOLR-646 > URL: https://issues.apache.org/jira/browse/SOLR-646 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Henri Biestro >Assignee: Shalin Shekhar Mangar > Fix For: 1.3 > > Attachments: solr-646.patch, SOLR-646.patch, solr-646.patch, > solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch > > > This patch refers to 'generalized configuration properties' as specified by > [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=1
[jira] Commented: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624467#action_12624467
]
Henri Biestro commented on SOLR-646:
0 - I *do* use today an include mechanism of some sort so my field types are
not defined in the schema; this allows to automate the schema generation from
another tool & not have to deal with copying content.
1 - the CoreContainer evaluator is a "transient" being; it keeps track of
properties as they are "read" and how they are evaluated during configuration.
It is not stored nor kept beyond the scope of load().
I dont see what you mean by house keeping. The things we keep afterwards are
property expressions (1 map in CoreContainer & 1 map per core) and 1 Properties
instance per CoreContainer & per map.
2 - The CoreContainer Evaluator is the part that declares properties, assign
them a scope, etc. The code is fairly well commented so I dont really get your
comment. Anyway, it is necessary, for persistence to be idempotent, ie we
should be able to write what we (just) read as in SolrProperties test, we need
to keep these around.
The Config evaluator is dealing with the include so I wont get there since ...
3 - To keep the evaluator so we can extract the pieces of information it
collected (cf 1). The loaderProperties are filled in by the evaluator as the
last step of its subsituteProperties method. We have to do it at the end so the
original evaluation scope is preserved during the whole evaluation.
4 - You misinterpret my example; when I'm changing some indexing/schema
configuration in an heavy way, I like to be able to test it before, etc; these
changes (like changing stemmer, synonyms, etc) require reindexing. So, the
version I'm talking about is the 'index data' version.
5 - I believe I did not remove any public method in the patch, did I?
6 - The visitor pattern used in the original substituteSystemProperties has
just been 'methodified'. The code is no different than what it was and it
allows to implement just what's needed by derivation.
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-646.patch, SOLR-646.patch, solr-646.patch,
> solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in *solr.xml*.
> h3. Use cases:
> Describe core data directories from solr.xml as properties.
> Share the same schema and/or config file between multiple cores.
> Share reusable fragments of schema & configuration between multiple cores.
> h3. Usage:
> h4. solr.xml
> This *solr.xml* will be used to illustrates using properties for different
> purpose.
> {code:xml}
>
> 1.3
> english, french
> en,core0
> fr,core1
>
>
> 3.5
> EN
> core0
> This is a sample
>
>
> 2.4
> FR
> core1
> Ceci est un exemple
>
>
>
> {code}
> {{version}} : if you update your solr.xml or your cores for various motives,
> it can be useful to track of a version. In this example, this will be used to
> define the {{dataDir}} for each core.
> {{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive,
> it might be convenient to use a property that can then be used to describe
> the Solr core name.
> {{instanceDir}}: note that both cores will use the same instance directory,
> sharing their configuration and schema. The {{dataDir}} will be set for each
> of them from the *solrconfig.xml*.
> h4. solrconfig.xml
> This is where our *solr.xml* property are used to define the data directory
> as a composition of, in our example, the language code {{l10n}} and the core
> version stored in {{version}}.
> {code:xml}
>
> ${solr.solr.home}/data/${l10n}-${version}
>
>
> {code}
> h5. schema.xml
> The {{include}} allows to import a file within the schema (or a solrconfig);
> this can help de-clutter long schemas.
> The {{ctlField}} is just illustrating that a field & its type can be set
> through properties as well; in our example, we will want the 'english' core
> to refer to an 'english-configured' field and the 'french' core to a
> 'french-configured' one. The type for the field is defined as {{text-EN}} or
> {{text-FR}} after expansion.
> {code:xml}
>
>
> ...
>
>
>
> ...
>stored="true" mu
[jira] Commented: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624450#action_12624450
]
Henri Biestro commented on SOLR-646:
The "ant-ish" syntax is certainly more common; I'll fix this.
{{code}}
{{code}}
About the include; I do have the use case and it does make my solrconfig &
schema more readable. And HossMan did not rule it out as a "no no".
I understand that there are mixed fillings about it though; what about putting
it in with an "experimental" state? (big warning & boolean in solr.xml).
So we can have the discussion after letting people experiment; if response is
bad or there are technical reasons to remove it, we'll just remove the code and
be done (much easier than adding it later).
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-646.patch, SOLR-646.patch, solr-646.patch,
> solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in *solr.xml*.
> h3. Use cases:
> Describe core data directories from solr.xml as properties.
> Share the same schema and/or config file between multiple cores.
> Share reusable fragments of schema & configuration between multiple cores.
> h3. Usage:
> h4. solr.xml
> This *solr.xml* will be used to illustrates using properties for different
> purpose.
> {code:xml}
>
> 1.3
> english, french
> en,core0
> fr,core1
>
>
> 3.5
> EN
> core0
> This is a sample
>
>
> 2.4
> FR
> core1
> Ceci est un exemple
>
>
>
> {code}
> {{version}} : if you update your solr.xml or your cores for various motives,
> it can be useful to track of a version. In this example, this will be used to
> define the {{dataDir}} for each core.
> {{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive,
> it might be convenient to use a property that can then be used to describe
> the Solr core name.
> {{instanceDir}}: note that both cores will use the same instance directory,
> sharing their configuration and schema. The {{dataDir}} will be set for each
> of them from the *solrconfig.xml*.
> h4. solrconfig.xml
> This is where our *solr.xml* property are used to define the data directory
> as a composition of, in our example, the language code {{l10n}} and the core
> version stored in {{version}}.
> {code:xml}
>
> ${solr.solr.home}/data/${l10n}-${version}
>
>
> {code}
> h5. schema.xml
> The {{include}} allows to import a file within the schema (or a solrconfig);
> this can help de-clutter long schemas.
> The {{ctlField}} is just illustrating that a field & its type can be set
> through properties as well; in our example, we will want the 'english' core
> to refer to an 'english-configured' field and the 'french' core to a
> 'french-configured' one. The type for the field is defined as {{text-EN}} or
> {{text-FR}} after expansion.
> {code:xml}
>
>
> ...
>
>
>
> ...
>stored="true" multiValued="true" />
>
> {code}
> This schema is importing this *text-l10n.xml* file which is a *fragment*; the
> fragment tag must be present & indicates the file is to be included. Our
> example only defines different stopwords for each language but you could of
> course extend this to stemmers, synonyms, etc.
> {code:xml}
>
>positionIncrementGap="100">
> ...
>words="stopwords-fr.txt"/>
> ...
>
>positionIncrementGap="100">
> ...
>words="stopwords-en.txt"/>
> ...
>
>
> {code}
> h4. Technical specifications
> solr.xml can define properties at the multicore & each core level.
> Properties defined in the multicore scope can override system properties.
> Properties defined in a core scope can override multicore & system properties.
> Property definitions can use expressions to define their name & value; these
> expressions are evaluated in their outer scope context .
> CoreContainer serialization keeps properties as defined; persistence is
> idem-potent. (ie property expressions are written, not their evaluation).
> The core descriptor properties are automatically defined in each core
> context, namely:
> solr.core.instanceDir
> solr.core.name
> solr.core.configName
> solr.core.schemaName
> h3. Coding notes:
> - DOMUtil.java:
> refactored s
[jira] Issue Comment Edited: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624450#action_12624450
]
henrib edited comment on SOLR-646 at 8/21/08 11:56 AM:
--
The "ant-ish" syntax is certainly more common; I'll fix this.
{code}
{code}
About the include; I do have the use case and it does make my solrconfig &
schema more readable. And HossMan did not rule it out as a "no no".
I understand that there are mixed fillings about it though; what about putting
it in with an "experimental" state? (big warning & boolean in solr.xml).
So we can have the discussion after letting people experiment; if response is
bad or there are technical reasons to remove it, we'll just remove the code and
be done (much easier than adding it later).
was (Author: henrib):
The "ant-ish" syntax is certainly more common; I'll fix this.
{{code}}
{{code}}
About the include; I do have the use case and it does make my solrconfig &
schema more readable. And HossMan did not rule it out as a "no no".
I understand that there are mixed fillings about it though; what about putting
it in with an "experimental" state? (big warning & boolean in solr.xml).
So we can have the discussion after letting people experiment; if response is
bad or there are technical reasons to remove it, we'll just remove the code and
be done (much easier than adding it later).
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-646.patch, SOLR-646.patch, solr-646.patch,
> solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in *solr.xml*.
> h3. Use cases:
> Describe core data directories from solr.xml as properties.
> Share the same schema and/or config file between multiple cores.
> Share reusable fragments of schema & configuration between multiple cores.
> h3. Usage:
> h4. solr.xml
> This *solr.xml* will be used to illustrates using properties for different
> purpose.
> {code:xml}
>
> 1.3
> english, french
> en,core0
> fr,core1
>
>
> 3.5
> EN
> core0
> This is a sample
>
>
> 2.4
> FR
> core1
> Ceci est un exemple
>
>
>
> {code}
> {{version}} : if you update your solr.xml or your cores for various motives,
> it can be useful to track of a version. In this example, this will be used to
> define the {{dataDir}} for each core.
> {{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive,
> it might be convenient to use a property that can then be used to describe
> the Solr core name.
> {{instanceDir}}: note that both cores will use the same instance directory,
> sharing their configuration and schema. The {{dataDir}} will be set for each
> of them from the *solrconfig.xml*.
> h4. solrconfig.xml
> This is where our *solr.xml* property are used to define the data directory
> as a composition of, in our example, the language code {{l10n}} and the core
> version stored in {{version}}.
> {code:xml}
>
> ${solr.solr.home}/data/${l10n}-${version}
>
>
> {code}
> h5. schema.xml
> The {{include}} allows to import a file within the schema (or a solrconfig);
> this can help de-clutter long schemas.
> The {{ctlField}} is just illustrating that a field & its type can be set
> through properties as well; in our example, we will want the 'english' core
> to refer to an 'english-configured' field and the 'french' core to a
> 'french-configured' one. The type for the field is defined as {{text-EN}} or
> {{text-FR}} after expansion.
> {code:xml}
>
>
> ...
>
>
>
> ...
>stored="true" multiValued="true" />
>
> {code}
> This schema is importing this *text-l10n.xml* file which is a *fragment*; the
> fragment tag must be present & indicates the file is to be included. Our
> example only defines different stopwords for each language but you could of
> course extend this to stemmers, synonyms, etc.
> {code:xml}
>
>positionIncrementGap="100">
> ...
>words="stopwords-fr.txt"/>
> ...
>
>positionIncrementGap="100">
> ...
>words="stopwords-en.txt"/>
> ...
>
>
> {code}
> h4. Technical specifications
> solr.xml can define properties at the multicore & each core level.
> Properties defined
[jira] Updated: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-646:
---
Description:
This patch refers to 'generalized configuration properties' as specified by
[HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
This means configuration & schema files can use expression based on properties
defined in *solr.xml*.
h3. Use cases:
Describe core data directories from solr.xml as properties.
Share the same schema and/or config file between multiple cores.
Share reusable fragments of schema & configuration between multiple cores.
h3. Usage:
h4. solr.xml
This *solr.xml* will be used to illustrates using properties for different
purpose.
{code:xml}
1.3
english, french
en,core0
fr,core1
3.5
EN
core0
This is a sample
2.4
FR
core1
Ceci est un exemple
{code}
{{version}} : if you update your solr.xml or your cores for various motives, it
can be useful to track of a version. In this example, this will be used to
define the {{dataDir}} for each core.
{{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive, it
might be convenient to use a property that can then be used to describe the
Solr core name.
{{instanceDir}}: note that both cores will use the same instance directory,
sharing their configuration and schema. The {{dataDir}} will be set for each of
them from the *solrconfig.xml*.
h4. solrconfig.xml
This is where our *solr.xml* property are used to define the data directory as
a composition of, in our example, the language code {{l10n}} and the core
version stored in {{version}}.
{code:xml}
${solr.solr.home}/data/${l10n}-${version}
{code}
h5. schema.xml
The {{include}} allows to import a file within the schema (or a solrconfig);
this can help de-clutter long schemas.
The {{ctlField}} is just illustrating that a field & its type can be set
through properties as well; in our example, we will want the 'english' core to
refer to an 'english-configured' field and the 'french' core to a
'french-configured' one. The type for the field is defined as {{text-EN}} or
{{text-FR}} after expansion.
{code:xml}
...
...
{code}
This schema is importing this *text-l10n.xml* file which is a *fragment*; the
fragment tag must be present & indicates the file is to be included. Our
example only defines different stopwords for each language but you could of
course extend this to stemmers, synonyms, etc.
{code:xml}
...
...
...
...
{code}
h4. Technical specifications
solr.xml can define properties at the multicore & each core level.
Properties defined in the multicore scope can override system properties.
Properties defined in a core scope can override multicore & system properties.
Property definitions can use expressions to define their name & value; these
expressions are evaluated in their outer scope context .
CoreContainer serialization keeps properties as defined; persistence is
idem-potent. (ie property expressions are written, not their evaluation).
The core descriptor properties are automatically defined in each core context,
namely:
solr.core.instanceDir
solr.core.name
solr.core.configName
solr.core.schemaName
h3. Coding notes:
- DOMUtil.java:
refactored substituteSystemProperties to use an Evaluator;
an Evaluator is a DOM visitor that expands property expressions "in place"
using a property map as an evaluation context
added an asString(node) method for logging purpose
- CoreDescriptor.java:
added an expression member to keep property expressions as defined in solr.xml
for persistence - allowing to write file as defined (not as expanded)
- CoreContainer.java:
add an expression member to keep property expression as defined in solr.xml for
persistence - allowing to write file as defined (not as expanded);
solrx.xml peristence is idem-potent
added a local DOMUtil.Evaluator that tracks property expressions to evaluate &
store them
*issues outlined through solr-646:*
fix in load:
CoreDescriptor p = new CoreDescriptor(this, names, );
was: CoreDescriptor p = new CoreDescriptor(this, name, ...);
fix in load;
register(aliases.get(a), core, false);
was of register(aliases.get(i), core, false);
- CoreAdminHandler.java
added an optional fileName to persist so it is possible to write the solr.xml
to a different file (for comparison purpose)
- CoreAdminRequest.java
added PersistRequest to allow passing optional fileName
- Config.java:
subsituteProperties has been moved out of constructor & doc member made
protected to allow override
added an IncludesEvaluator that deals with include/fragment
- SolrConfig.java & IndexSchema.ava
added explicit calls to substituteProperties to perform property/in
[jira] Updated: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-646:
---
Description:
This patch refers to 'generalized configuration properties' as specified by
[HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
This means configuration & schema files can use expression based on properties
defined in *solr.xml*.
h3. Use cases:
Describe core data directories from solr.xml as properties.
Share the same schema and/or config file between multiple cores.
Share reusable fragments of schemar & configuration between multiple cores.
h3. Usage:
h4. solr.xml
This *solr.xml* will be used to illustrates using properties for different
purpose.
{code:xml}
1.3
english, french
en,core0
fr,core1
3.5
EN
core0
This is a sample
2.4
FR
core1
Ceci est un exemple
{code}
{{version}} : if you update your solr.xml or your cores for various motives, it
can be useful to track of a version. In this example, this will be used to
define the {{dataDir}} for each core.
{{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive, it
might be convenient to use a property that can then be used to describe the
Solr core name.
{{instanceDir}}: note that both cores will use the same instance directory,
sharing their configuration and schema. The {{dataDir}} will be set for each of
them from the *solrconfig.xml*.
h4. solrconfig.xml
This is where our *solr.xml* property are used to define the data directory as
a composition of, in our example, the language code {{l10n}} and the core
version stored in {{version}}.
{code:xml}
${solr.solr.home}/data/${l10n}-${version}
{code}
h5. schema.xml
The {{include}} allows to import a file within the schema (or a solrconfig);
this can help de-clutter long schemas.
The {{ctlField}} is just illustrating that a field & its type can be set
through properties as well; in our example, we will want the 'english' core to
refer to an 'english-configured' field and the 'french' core to a
'french-configured' one. The type for the field is defined as {{text-EN}} or
{{text-FR}} after expansion.
{code:xml}
...
...
{code}
This schema is importing this* text-l10n.xml* file which is a *fragment*; the
fragment tag must be present & indicates the file is to be included. Our
example only defines different stopwords for each language but you could of
course extend this to stemmers, synonyms, etc.
{code:xml}
...
...
...
...
{code}
h4. Technical specifications
solr.xml can define properties at the multicore & each core level.
Properties defined in the multicore scope can override system properties.
Properties defined in a core scope can override multicore & system properties.
Property definitions can use expressions to define their name & value; these
expressions are evaluated in their outer scope context .
CoreContainer serialization keeps properties as defined; persistence is
idem-potent. (ie property expressions are written, not their evaluation).
The core descriptor properties are automatically defined in each core context,
namely:
solr.core.instanceDir
solr.core.name
solr.core.configName
solr.core.schemaName
h3. Coding notes:
- DOMUtil.java:
refactored substituteSystemProperties to use an Evaluator;
an Evaluator is a DOM visitor that expands property expressions "in place"
using a property map as an evaluation context
added an asString(node) method for logging purpose
- CoreDescriptor.java:
added an expression member to keep property expressions as defined in solr.xml
for persistence - allowing to write file as defined (not as expanded)
- CoreContainer.java:
add an expression member to keep property expression as defined in solr.xml for
persistence - allowing to write file as defined (not as expanded);
solrx.xml peristence is idem-potent
added a local DOMUtil.Evaluator that tracks property expressions to evaluate &
store them
*issues outlined through solr-646:*
fix in load:
CoreDescriptor p = new CoreDescriptor(this, names, );
was: CoreDescriptor p = new CoreDescriptor(this, name, ...);
fix in load;
register(aliases.get(a), core, false);
was of register(aliases.get(i), core, false);
- CoreAdminHandler.java
added an optional fileName to persist so it is possible to write the solr.xml
to a different file (for comparison purpose)
- CoreAdminRequest.java
added PersistRequest to allow passing optional fileName
- Config.java:
subsituteProperties has been moved out of constructor & doc member made
protected to allow override
added an IncludesEvaluator that deals with include/fragment
- SolrConfig.java & IndexSchema.ava
added explicit calls to substituteProperties to perform property/i
[jira] Issue Comment Edited: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624369#action_12624369
]
henrib edited comment on SOLR-646 at 8/21/08 7:43 AM:
-
New leaner version since there was indeed a simpler way to achieve the same
(reviewing & friendly pressure does help to improve, thanks Shalin).
Fewer classes modified so the bulk of the code deals with going through XML
configuration.
I also removed loading properties from 'solr.properties' which was useless as
it was.
Added a specific persistence verification & a multicore inspired test to verify
shared schema/config configuration.
I updated the issue description to reflect the patch feature & reasons for code
modification in Coding Notes (intended to help review).
patch applied cleanly with 'patch -u -p0 < solr-646.patch' on trunk 687771
was (Author: henrib):
New leaner version since there was indeed a simpler way to achieve the same
(reviewing & friendly pressure does help to improve, thanks Shalin).
Fewer classes modified so the bulk of the code deals with going through XML
configuration.
I also removed loading properties from 'solr.properties' which was useless as
it was.
Added a specific persistence verification & a multicore inspired test to verify
shared schema/config configuration.
I updated the issue description to reflect the patch feature & reasons for code
modification in Coding Notes (intended to help review).
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-646.patch, SOLR-646.patch, solr-646.patch,
> solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in multicore.xml.
> h3. Use cases:
> Describe core data directories from solr.xml as properties.
> Share the same schema and/or config file between multiple cores.
> Share reusable fragments of schemar & configuration between multiple cores.
> h3. Usage:
> h4. solr.xml
> This*solr.xml* will be used to illustrates using properties for different
> purpose.
> {code:xml}
>
> 1.3
> english, french
> en,core0
> fr,core1
>
>
> 3.5
> EN
> core0
> This is a sample
>
>
> 2.4
> FR
> core1
> Ceci est un exemple
>
>
>
> {code}
> {{version}} : if you update your solr.xml or your cores for various motives,
> it can be useful to track of a version. In this example, this will be used to
> define the {{dataDir}} for each core.
> {{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive,
> it might be convenient to use a property that can then be used to describe
> the Solr core name.
> {{instanceDir}}: note that both cores will use the same instance directory,
> sharing their configuration and schema. The {{dataDir}} will be set for each
> of them from the *solrconfig.xml*.
> h4. solrconfig.xml
> This is where our *solr.xml* property are used to define the data directory
> as a composition of, in our example, the language code {{l10n}} and the core
> version stored in {{version}}.
> {code:xml}
>
> ${solr.solr.home}/data/${l10n}-${version}
>
>
> {code}
> h5. schema.xml
> The {{include}} allows to import a file within the schema (or a solrconfig);
> this can help de-clutter long schemas.
> The {{ctlField}} is just illustrating that a field & its type can be set
> through properties as well; in our example, we will want the 'english' core
> to refer to an 'english-configured' field and the 'french' core to a
> 'french-configured' one. The type for the field is defined as {{text-EN}} or
> {{text-FR}} after expansion.
> {code:xml}
>
>
> ...
>
>
>
> ...
>stored="true" multiValued="true" />
>
> {code}
> This schema is importing this* text-l10n.xml* file which is a *fragment*; the
> fragment tag must be present & indicates the file is to be included. Our
> example only defines different stopwords for each language but you could of
> course extend this to stemmers, synonyms, etc.
> {code:xml}
>
>positionIncrementGap="100">
> ...
>words="stopwords-fr.txt"/>
> ...
>
>positionIncrementGap="100">
> ...
>words="stopwords-en.txt"/>
> ...
>
>
> {code}
> h4. Technical specifications
> solr.xml can
[jira] Issue Comment Edited: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624369#action_12624369
]
henrib edited comment on SOLR-646 at 8/21/08 7:27 AM:
-
New leaner version since there was indeed a simpler way to achieve the same
(reviewing & friendly pressure does help to improve, thanks Shalin).
Fewer classes modified so the bulk of the code deals with going through XML
configuration.
I also removed loading properties from 'solr.properties' which was useless as
it was.
Added a specific persistence verification & a multicore inspired test to verify
shared schema/config configuration.
I updated the issue description to reflect the patch feature & reasons for code
modification in Coding Notes (intended to help review).
was (Author: henrib):
New leaner version since there was indeed a simpler way to achieve the same
(reviewing does help to improve, thanks Shalin).
Added a specific persistence verification & a multicore inspired test to verify
shared schema/config configuration.
I updated the issue description to reflect the patch feature & reasons for code
modification in Coding Notes (intended to help review).
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-646.patch, SOLR-646.patch, solr-646.patch,
> solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in multicore.xml.
> h3. Use cases:
> Describe core data directories from solr.xml as properties.
> Share the same schema and/or config file between multiple cores.
> Share reusable fragments of schemar & configuration between multiple cores.
> h3. Usage:
> h4. solr.xml
> This*solr.xml* will be used to illustrates using properties for different
> purpose.
> {code:xml}
>
> 1.3
> english, french
> en,core0
> fr,core1
>
>
> 3.5
> EN
> core0
> This is a sample
>
>
> 2.4
> FR
> core1
> Ceci est un exemple
>
>
>
> {code}
> {{version}} : if you update your solr.xml or your cores for various motives,
> it can be useful to track of a version. In this example, this will be used to
> define the {{dataDir}} for each core.
> {{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive,
> it might be convenient to use a property that can then be used to describe
> the Solr core name.
> {{instanceDir}}: note that both cores will use the same instance directory,
> sharing their configuration and schema. The {{dataDir}} will be set for each
> of them from the *solrconfig.xml*.
> h4. solrconfig.xml
> This is where our *solr.xml* property are used to define the data directory
> as a composition of, in our example, the language code {{l10n}} and the core
> version stored in {{version}}.
> {code:xml}
>
> ${solr.solr.home}/data/${l10n}-${version}
>
>
> {code}
> h5. schema.xml
> The {{include}} allows to import a file within the schema (or a solrconfig);
> this can help de-clutter long schemas.
> The {{ctlField}} is just illustrating that a field & its type can be set
> through properties as well; in our example, we will want the 'english' core
> to refer to an 'english-configured' field and the 'french' core to a
> 'french-configured' one. The type for the field is defined as {{text-EN}} or
> {{text-FR}} after expansion.
> {code:xml}
>
>
> ...
>
>
>
> ...
>stored="true" multiValued="true" />
>
> {code}
> This schema is importing this* text-l10n.xml* file which is a *fragment*; the
> fragment tag must be present & indicates the file is to be included. Our
> example only defines different stopwords for each language but you could of
> course extend this to stemmers, synonyms, etc.
> {code:xml}
>
>positionIncrementGap="100">
> ...
>words="stopwords-fr.txt"/>
> ...
>
>positionIncrementGap="100">
> ...
>words="stopwords-en.txt"/>
> ...
>
>
> {code}
> h4. Technical specifications
> solr.xml can define properties at the multicore & each core level.
> Properties defined in the multicore scope can override system properties.
> Properties defined in a core scope can override multicore & system properties.
> Property definitions can use expressions to define their name
[jira] Issue Comment Edited: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624369#action_12624369
]
henrib edited comment on SOLR-646 at 8/21/08 7:19 AM:
-
New leaner version since there was indeed a simpler way to achieve the same
(reviewing does help to improve, thanks Shalin).
Added a specific persistence verification & a multicore inspired test to verify
shared schema/config configuration.
I updated the issue description to reflect the patch feature & reasons for code
modification in Coding Notes (intended to help review).
was (Author: henrib):
New leaner version since there was indeed a simpler way to achieve the same
(reviewing does help to improve, thanks Shalin).
Added a specific persistence verification & a multicore inspired test to verify
shared schema/config configuration.
I updated the issue description to reflect the patch feature & reasons for code
modification.
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-646.patch, SOLR-646.patch, solr-646.patch,
> solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in multicore.xml.
> h3. Use cases:
> Describe core data directories from solr.xml as properties.
> Share the same schema and/or config file between multiple cores.
> Share reusable fragments of schemar & configuration between multiple cores.
> h3. Usage:
> h4. solr.xml
> This*solr.xml* will be used to illustrates using properties for different
> purpose.
> {code:xml}
>
> 1.3
> english, french
> en,core0
> fr,core1
>
>
> 3.5
> EN
> core0
> This is a sample
>
>
> 2.4
> FR
> core1
> Ceci est un exemple
>
>
>
> {code}
> {{version}} : if you update your solr.xml or your cores for various motives,
> it can be useful to track of a version. In this example, this will be used to
> define the {{dataDir}} for each core.
> {{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive,
> it might be convenient to use a property that can then be used to describe
> the Solr core name.
> {{instanceDir}}: note that both cores will use the same instance directory,
> sharing their configuration and schema. The {{dataDir}} will be set for each
> of them from the *solrconfig.xml*.
> h4. solrconfig.xml
> This is where our *solr.xml* property are used to define the data directory
> as a composition of, in our example, the language code {{l10n}} and the core
> version stored in {{version}}.
> {code:xml}
>
> ${solr.solr.home}/data/${l10n}-${version}
>
>
> {code}
> h5. schema.xml
> The {{include}} allows to import a file within the schema (or a solrconfig);
> this can help de-clutter long schemas.
> The {{ctlField}} is just illustrating that a field & its type can be set
> through properties as well; in our example, we will want the 'english' core
> to refer to an 'english-configured' field and the 'french' core to a
> 'french-configured' one. The type for the field is defined as {{text-EN}} or
> {{text-FR}} after expansion.
> {code:xml}
>
>
> ...
>
>
>
> ...
>stored="true" multiValued="true" />
>
> {code}
> This schema is importing this* text-l10n.xml* file which is a *fragment*; the
> fragment tag must be present & indicates the file is to be included. Our
> example only defines different stopwords for each language but you could of
> course extend this to stemmers, synonyms, etc.
> {code:xml}
>
>positionIncrementGap="100">
> ...
>words="stopwords-fr.txt"/>
> ...
>
>positionIncrementGap="100">
> ...
>words="stopwords-en.txt"/>
> ...
>
>
> {code}
> h4. Technical specifications
> solr.xml can define properties at the multicore & each core level.
> Properties defined in the multicore scope can override system properties.
> Properties defined in a core scope can override multicore & system properties.
> Property definitions can use expressions to define their name & value; these
> expressions are evaluated in their outer scope context .
> CoreContainer serialization keeps properties as defined; persistence is
> idem-potent. (ie property expressions are written, not their evaluation).
> The core descr
[jira] Updated: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-646:
---
Description:
This patch refers to 'generalized configuration properties' as specified by
[HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
This means configuration & schema files can use expression based on properties
defined in multicore.xml.
h3. Use cases:
Describe core data directories from solr.xml as properties.
Share the same schema and/or config file between multiple cores.
Share reusable fragments of schemar & configuration between multiple cores.
h3. Usage:
h4. solr.xml
This*solr.xml* will be used to illustrates using properties for different
purpose.
{code:xml}
1.3
english, french
en,core0
fr,core1
3.5
EN
core0
This is a sample
2.4
FR
core1
Ceci est un exemple
{code}
{{version}} : if you update your solr.xml or your cores for various motives, it
can be useful to track of a version. In this example, this will be used to
define the {{dataDir}} for each core.
{{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive, it
might be convenient to use a property that can then be used to describe the
Solr core name.
{{instanceDir}}: note that both cores will use the same instance directory,
sharing their configuration and schema. The {{dataDir}} will be set for each of
them from the *solrconfig.xml*.
h4. solrconfig.xml
This is where our *solr.xml* property are used to define the data directory as
a composition of, in our example, the language code {{l10n}} and the core
version stored in {{version}}.
{code:xml}
${solr.solr.home}/data/${l10n}-${version}
{code}
h5. schema.xml
The {{include}} allows to import a file within the schema (or a solrconfig);
this can help de-clutter long schemas.
The {{ctlField}} is just illustrating that a field & its type can be set
through properties as well; in our example, we will want the 'english' core to
refer to an 'english-configured' field and the 'french' core to a
'french-configured' one. The type for the field is defined as {{text-EN}} or
{{text-FR}} after expansion.
{code:xml}
...
...
{code}
This schema is importing this* text-l10n.xml* file which is a *fragment*; the
fragment tag must be present & indicates the file is to be included. Our
example only defines different stopwords for each language but you could of
course extend this to stemmers, synonyms, etc.
{code:xml}
...
...
...
...
{code}
h4. Technical specifications
solr.xml can define properties at the multicore & each core level.
Properties defined in the multicore scope can override system properties.
Properties defined in a core scope can override multicore & system properties.
Property definitions can use expressions to define their name & value; these
expressions are evaluated in their outer scope context .
CoreContainer serialization keeps properties as defined; persistence is
idem-potent. (ie property expressions are written, not their evaluation).
The core descriptor properties are automatically defined in each core context,
namely:
solr.core.instanceDir
solr.core.name
solr.core.configName
solr.core.schemaName
h3. Coding notes:
- DOMUtil.java:
refactored substituteSystemProperties to use an Evaluator;
an Evaluator is a DOM visitor that expands property expressions "in place"
using a property map as an evaluation context
added an asString(node) method for logging purpose
- CoreDescriptor.java:
added an expression member to keep property expressions as defined in solr.xml
for persistence - allowing to write file as defined (not as expanded)
- CoreContainer.java:
add an expression member to keep property expression as defined in solr.xml for
persistence - allowing to write file as defined (not as expanded);
solrx.xml peristence is idem-potent
added a local DOMUtil.Evaluator that tracks property expressions to evaluate &
store them
*issues outlined through solr-646:*
fix in load:
CoreDescriptor p = new CoreDescriptor(this, names, );
was: CoreDescriptor p = new CoreDescriptor(this, name, ...);
fix in load;
register(aliases.get(a), core, false);
was of register(aliases.get(i), core, false);
- CoreAdminHandler.java
added an optional fileName to persist so it is possible to write the solr.xml
to a different file (for comparison purpose)
- CoreAdminRequest.java
added PersistRequest to allow passing optional fileName
- Config.java:
subsituteProperties has been moved out of constructor & doc member made
protected to allow override
added an IncludesEvaluator that deals with include/fragment
- SolrConfig.java & IndexSchema.ava
added explicit calls to substituteProperties to perform property
[jira] Issue Comment Edited: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624369#action_12624369
]
henrib edited comment on SOLR-646 at 8/21/08 7:15 AM:
-
New leaner version since there was indeed a simpler way to achieve the same
(reviewing does help to improve, thanks Shalin).
Added a specific persistence verification & a multicore inspired test to verify
shared schema/config configuration.
I updated the issue description to reflect the patch feature & reasons for code
modification.
was (Author: henrib):
New stripped down version since there was indeed a leaner way to achieve
the same (reviewing does help to improve, thanks Shalin).
Added a specific persistence verification & a multicore inspired test to verify
shared schema/config configuration.
I'll update the issue description to reflect the patch code.
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-646.patch, SOLR-646.patch, solr-646.patch,
> solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in multicore.xml.
> h3. Use cases:
> Describe core data directories from solr.xml as properties.
> Share the same schema and/or config file between multiple cores.
> Share reusable fragments of schemar & configuration between multiple cores.
> h3. Usage:
> h4. solr.xml
> This*solr.xml* will be used to illustrates using properties for different
> purpose.
> {code:xml}
>
> 1.3
> english, french
> en,core0
> fr,core1
>
>
> 3.5
> EN
> core0
> This is a sample
>
>
> 2.4
> FR
> core1
> Ceci est un exemple
>
>
>
> {code}
> {{version}} : if you update your solr.xml or your cores for various motives,
> it can be useful to track of a version. In this example, this will be used to
> define the {{dataDir}} for each core.
> {{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive,
> it might be convenient to use a property that can then be used to describe
> the Solr core name.
> {{instanceDir}}: note that both cores will use the same instance directory,
> sharing their configuration and schema. The {{dataDir}} will be set for each
> of them from the *solrconfig.xml*.
> h4. solrconfig.xml
> This is where our *solr.xml* property are used to define the data directory
> as a composition of, in our example, the language code {{l10n}} and the core
> version stored in {{version}}.
> {code:xml}
>
> ${solr.solr.home}/data/${l10n}-${version}
>
>
> {code}
> h5. schema.xml
> The {{include}} allows to import a file within the schema (or a solrconfig);
> this can help de-clutter long schemas.
> The {{ctlField}} is just illustrating that a field & its type can be set
> through properties as well; in our example, we will want the 'english' core
> to refer to an 'english-configured' field and the 'french' core to a
> 'french-configured' one. The type for the field is defined as {{text-EN}} or
> {{text-FR}} after expansion.
> {code:xml}
>
>
> ...
>
>
>
> ...
>stored="true" multiValued="true" />
>
> {code}
> This schema is importing this* text-l10n.xml* file which is a *fragment*; the
> fragment tag must be present & indicates the file is to be included. Our
> example only defines different stopwords for each language but you could of
> course extend this to stemmers, synonyms, etc.
> {code:xml}
>
>positionIncrementGap="100">
> ...
>words="stopwords-fr.txt"/>
> ...
>
>positionIncrementGap="100">
> ...
>words="stopwords-en.txt"/>
> ...
>
>
> {code}
> h4. Technical specifications
> solr.xml can define properties at the multicore & each core level.
> Properties defined in the multicore scope can override system properties.
> Properties defined in a core scope can override multicore & system properties.
> Property definitions can use expressions to define their name & value; these
> expressions are evaluated in their outer scope context .
> CoreContainer serialization keeps properties as defined; persistence is
> idem-potent. (ie property expressions are written, not their evaluation).
> The core descriptor properties are automatically defined in each core
> context, na
[jira] Updated: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-646:
---
Description:
This patch refers to 'generalized configuration properties' as specified by
[HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
This means configuration & schema files can use expression based on properties
defined in multicore.xml.
h3. Use cases:
Describe core data directories from solr.xml as properties.
Share the same schema and/or config file between multiple cores.
Share reusable fragments of schemar & configuration between multiple cores.
h3. Usage:
h4. solr.xml
This*solr.xml* will be used to illustrates using properties for different
purpose.
{code:xml}
1.3
english, french
en,core0
fr,core1
3.5
EN
core0
This is a sample
2.4
FR
core1
Ceci est un exemple
{code}
{{version}} : if you update your solr.xml or your cores for various motives, it
can be useful to track of a version. In this example, this will be used to
define the {{dataDir}} for each core.
{{en-cores}},{{fr-cores}}: with aliases, if the list is long or repetitive, it
might be convenient to use a property that can then be used to describe the
Solr core name.
{{instanceDir}}: note that both cores will use the same instance directory,
sharing their configuration and schema. The {{dataDir}} will be set for each of
them from the *solrconfig.xml*.
h4. solrconfig.xml
This is where our *solr.xml* property are used to define the data directory as
a composition of, in our example, the language code {{l10n}} and the core
version stored in {{version}}.
{code:xml}
${solr.solr.home}/data/${l10n}-${version}
{code}
h5. schema.xml
The {{include}} allows to import a file within the schema (or a solrconfig);
this can help de-clutter long schemas.
The {{ctlField}} is just illustrating that a field & its type can be set
through properties as well; in our example, we will want the 'english' core to
refer to an 'english-configured' field and the 'french' core to a
'french-configured' one. The type for the field is defined as {{text-EN}} or
{{text-FR}} after expansion.
{code:xml}
...
...
{code}
This schema is importing this* text-l10n.xml* file which is a *fragment*; the
fragment tag must be present & indicates the file is to be included. Our
example only defines different stopwords for each language but you could of
course extend this to stemmers, synonyms, etc.
{code:xml}
...
...
...
...
{code}
h4. Technical specifications
solr.xml can define properties at the multicore & each core level.
Properties defined in the multicore scope can override system properties.
Properties defined in a core scope can override multicore & system properties.
Property definitions can use expressions to define their name & value; these
expressions are evaluated in their outer scope context .
CoreContainer serialization keeps properties as defined; persistence is
idem-potent. (ie property expressions are written, not their evaluation).
The core descriptor properties are automatically defined in each core context,
namely:
solr.core.instanceDir
solr.core.name
solr.core.configName
solr.core.schemaName
h3. Coding notes:
DOMUtil.java:
refactored substituteSystemProperties to use an Evaluator;
an Evaluator is a DOM visitor that expands property expressions "in place"
using a property map as an evaluation context
added an asString(node) method for logging purpose
CoreDescriptor.java:
added an expression member to keep property expressions as defined in solr.xml
for persistence - allowing to write file as defined (not as expanded)
CoreContainer.java:
add an expression member to keep property expression as defined in solr.xml for
persistence - allowing to write file as defined (not as expanded);
solrx.xml peristence is idem-potent
added a local DOMUtil.Evaluator that tracks property expressions to evaluate &
store them
issues outlined through solr-646:
fix in load:
CoreDescriptor p = new CoreDescriptor(this, names, );
was: CoreDescriptor p = new CoreDescriptor(this, name, ...);
fix in load;
register(aliases.get(a), core, false);
was of register(aliases.get(i), core, false);
CoreAdminHandler.java
added an optional fileName to persist so it is possible to write the solr.xml
to a different file (for comparison purpose)
CoreAdminRequest.java
added PersistRequest to allow passing optional fileName
Config.java:
subsituteProperties has been moved out of constructor & doc member made
protected to allow override
added an IncludesEvaluator that deals with include/fragment
SolrConfig.java & IndexSchema.ava
added explicit calls to substituteProperties to perform property/include
expans
[jira] Updated: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-646:
---
Attachment: solr-646.patch
New stripped down version since there was indeed a leaner way to achieve the
same (reviewing does help to improve, thanks Shalin).
Added a specific persistence verification & a multicore inspired test to verify
shared schema/config configuration.
I'll update the issue description to reflect the patch code.
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: solr-646.patch, SOLR-646.patch, solr-646.patch,
> solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in multicore.xml.
> h3. Use cases:
> Share the same schema and/or config file between multiple cores but point to
> different dataDirs using a ${core.datadir}
> Change the general layout between data, config & schema directories.
> Define 'installation' wide properties (for replication for instance) in
> multicore.properties (different base/install/data directories on different
> hosts).
> h3. Syntax:
> h4. Defining properties:
> Either in the multicore.properties file (usual property format):
> {code:xml}
> env.value=an installation value
> env.other_value=another installation value
> {code}
> In the multicore.xml:
> {code:xml}
>
> a value
> ${env.value} }
>
> some value
> ${mp0}-and some data
>
>
> {code}
> h4. Using properties:
> Besides used defined properties, the following core descriptor properties are
> automatically defined in each core context, namely:
> {code}
> solr.core.instanceDir
> solr.core.instancePath
> solr.core.name
> solr.core.configName
> solr.core.schemaName
> {code}
> All properties can be used in any attribute or text node of a solrconfig.xml
> or schema.xml as in:
> {code:xml}
> ${core.dataDir}
> {code}
> h4. Technical specifications
> Multicore.xml can define properties at the multicore & each core level.
> Properties defined in the multicore scope can override system properties.
> Properties defined in a core scope can override multicore & system properties.
> Property definitions can use expressions to define their name & value; these
> expressions are evaluated in their outer scope context .
> Multicore serialization keeps properties as written (ie as expressions if
> they were defined so).
> The core descriptor properties are automatically defined in each core
> context, namely:
> solr.core.instanceDir
> solr.core.instancePath
> solr.core.name
> solr.core.configName
> solr.core.schemaName
> h4. Test:
> The following (contrived) multicore.xml:
> {code:xml}
>
> 33
> 0
> 1
> bogus
> bogus
>
> core${zero}_id
> solr.DirectUpdateHandler2
> 11
>
>
> core${one}_id
> solr.DirectUpdateHandler2
> 22
>
>
> {code}
> allows this config.xml:
> {code:xml}
>
>
>
>
> multipartUploadLimitInKB="2048" />
>
>
>default="true" />
>
>class="org.apache.solr.handler.admin.LukeRequestHandler" />
>
>
>
> solr
> solrconfig.xml schema.xml admin-extra.html
>
> qt=standard&q=solrpingquery
>
>
>
> {code}
> and this schema.xml:
> {code:xml}
>
>
>
> sortMissingLast="true" omitNorms="true"/>
> omitNorms="true"/>
>
>
>
>stored="true" multiValued="false" required="true"/>
>multiValued="false" />
>multiValued="false" />
>stored="true" multiValued="false" />
>
> id
> name
>
>
> {code}
> Allow the trunk test to work.
> h3. Coding notes:
> The code itself refactored some of DOMUtil (the ant based property
> substitution) into one added class (PropertyMap & PropertyMap.Evaluator).
> The PropertyMap are chained (one link chain between core to multicore map);
> those maps are owned by each core's ResourceLoader.
> Config is modified a little to accommodate delaying & specializing property
> expansions.
> Multicore is modified so it properly parses & serializes.
> Tested against the example above.
> Reviews & comments more than welcome.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624114#action_12624114
]
Henri Biestro commented on SOLR-646:
Not sure this is my place to comment since I'm no committer but I don't see
what this brings that the previous patch did not (and do see that 'import' or
sharing schema/config is not a feature that should be discussed)..
It would have been helpful to me to understand why the updated patch is not
even considered.
All yours then.
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: SOLR-646.patch, solr-646.patch, solr-646.patch,
> solr-646.patch, solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in multicore.xml.
> h3. Use cases:
> Share the same schema and/or config file between multiple cores but point to
> different dataDirs using a ${core.datadir}
> Change the general layout between data, config & schema directories.
> Define 'installation' wide properties (for replication for instance) in
> multicore.properties (different base/install/data directories on different
> hosts).
> h3. Syntax:
> h4. Defining properties:
> Either in the multicore.properties file (usual property format):
> {code:xml}
> env.value=an installation value
> env.other_value=another installation value
> {code}
> In the multicore.xml:
> {code:xml}
>
> a value
> ${env.value} }
>
> some value
> ${mp0}-and some data
>
>
> {code}
> h4. Using properties:
> Besides used defined properties, the following core descriptor properties are
> automatically defined in each core context, namely:
> {code}
> solr.core.instanceDir
> solr.core.instancePath
> solr.core.name
> solr.core.configName
> solr.core.schemaName
> {code}
> All properties can be used in any attribute or text node of a solrconfig.xml
> or schema.xml as in:
> {code:xml}
> ${core.dataDir}
> {code}
> h4. Technical specifications
> Multicore.xml can define properties at the multicore & each core level.
> Properties defined in the multicore scope can override system properties.
> Properties defined in a core scope can override multicore & system properties.
> Property definitions can use expressions to define their name & value; these
> expressions are evaluated in their outer scope context .
> Multicore serialization keeps properties as written (ie as expressions if
> they were defined so).
> The core descriptor properties are automatically defined in each core
> context, namely:
> solr.core.instanceDir
> solr.core.instancePath
> solr.core.name
> solr.core.configName
> solr.core.schemaName
> h4. Test:
> The following (contrived) multicore.xml:
> {code:xml}
>
> 33
> 0
> 1
> bogus
> bogus
>
> core${zero}_id
> solr.DirectUpdateHandler2
> 11
>
>
> core${one}_id
> solr.DirectUpdateHandler2
> 22
>
>
> {code}
> allows this config.xml:
> {code:xml}
>
>
>
>
> multipartUploadLimitInKB="2048" />
>
>
>default="true" />
>
>class="org.apache.solr.handler.admin.LukeRequestHandler" />
>
>
>
> solr
> solrconfig.xml schema.xml admin-extra.html
>
> qt=standard&q=solrpingquery
>
>
>
> {code}
> and this schema.xml:
> {code:xml}
>
>
>
> sortMissingLast="true" omitNorms="true"/>
> omitNorms="true"/>
>
>
>
>stored="true" multiValued="false" required="true"/>
>multiValued="false" />
>multiValued="false" />
>stored="true" multiValued="false" />
>
> id
> name
>
>
> {code}
> Allow the trunk test to work.
> h3. Coding notes:
> The code itself refactored some of DOMUtil (the ant based property
> substitution) into one added class (PropertyMap & PropertyMap.Evaluator).
> The PropertyMap are chained (one link chain between core to multicore map);
> those maps are owned by each core's ResourceLoader.
> Config is modified a little to accommodate delaying & specializing property
> expansions.
> Multicore is modified so it properly parses & serializes.
> Tested against the example above.
> Reviews & comments more than welcome.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-710) Solr cannot find jar's in Multicore sharedLib directory
[ https://issues.apache.org/jira/browse/SOLR-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623745#action_12623745 ] Henri Biestro commented on SOLR-710: There should be a comment in the log file stating the sharedLib absolute path directory beginning with "loading shared library: ...". This may help you diagnose. > Solr cannot find jar's in Multicore sharedLib directory > --- > > Key: SOLR-710 > URL: https://issues.apache.org/jira/browse/SOLR-710 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Andrew Nagy > Fix For: 1.3 > > > I am using the UnicodeNormalizationFilterFactory developed by Robert Haschart > and have added the jar to my solr/lib directory. This worked great until i > implemented the multicore with the solr.xml file. However now with the > multicore feature in place, solr can no longer find the jar containing the > unicode filter. > I set the sharedLib attribute to ./solr/lib, just lib and to > /usr/local/solr/lib - all three times I had the same result - it could not > find the jar. > When I copy the lib directory into my core directory (still with the > sharedLib dir set to ./solr/lib) everything works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-646:
---
Attachment: solr-646.patch
Refactored following HossMan recommendations.
This still includes the "include" (was import) feature but removing it is easy
(in Config.java) & will reduce modifications in ResourceLoader.java.
Added a specific test that loads a shared schema & config but uses properties
to differentiate behavior (different locales, different dataDirs).
Includes a one letter fix in CoreContainer.load for aliases (get(a) instead of
get(i)).
More tests will follow (persist verification is "manual") & I'll try to cut the
patch in 2 (properties - include).
I might be busier in the coming days but will try not to slow down 1.3 release
if next review says this is on the right track.
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Ryan McKinley
> Fix For: 1.3
>
> Attachments: solr-646.patch, solr-646.patch, solr-646.patch,
> solr-646.patch, solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in multicore.xml.
> h3. Use cases:
> Share the same schema and/or config file between multiple cores but point to
> different dataDirs using a ${core.datadir}
> Change the general layout between data, config & schema directories.
> Define 'installation' wide properties (for replication for instance) in
> multicore.properties (different base/install/data directories on different
> hosts).
> h3. Syntax:
> h4. Defining properties:
> Either in the multicore.properties file (usual property format):
> {code:xml}
> env.value=an installation value
> env.other_value=another installation value
> {code}
> In the multicore.xml:
> {code:xml}
>
> a value
> ${env.value} }
>
> some value
> ${mp0}-and some data
>
>
> {code}
> h4. Using properties:
> Besides used defined properties, the following core descriptor properties are
> automatically defined in each core context, namely:
> {code}
> solr.core.instanceDir
> solr.core.instancePath
> solr.core.name
> solr.core.configName
> solr.core.schemaName
> {code}
> All properties can be used in any attribute or text node of a solrconfig.xml
> or schema.xml as in:
> {code:xml}
> ${core.dataDir}
> {code}
> h4. Technical specifications
> Multicore.xml can define properties at the multicore & each core level.
> Properties defined in the multicore scope can override system properties.
> Properties defined in a core scope can override multicore & system properties.
> Property definitions can use expressions to define their name & value; these
> expressions are evaluated in their outer scope context .
> Multicore serialization keeps properties as written (ie as expressions if
> they were defined so).
> The core descriptor properties are automatically defined in each core
> context, namely:
> solr.core.instanceDir
> solr.core.instancePath
> solr.core.name
> solr.core.configName
> solr.core.schemaName
> h4. Test:
> The following (contrived) multicore.xml:
> {code:xml}
>
> 33
> 0
> 1
> bogus
> bogus
>
> core${zero}_id
> solr.DirectUpdateHandler2
> 11
>
>
> core${one}_id
> solr.DirectUpdateHandler2
> 22
>
>
> {code}
> allows this config.xml:
> {code:xml}
>
>
>
>
> multipartUploadLimitInKB="2048" />
>
>
>default="true" />
>
>class="org.apache.solr.handler.admin.LukeRequestHandler" />
>
>
>
> solr
> solrconfig.xml schema.xml admin-extra.html
>
> qt=standard&q=solrpingquery
>
>
>
> {code}
> and this schema.xml:
> {code:xml}
>
>
>
> sortMissingLast="true" omitNorms="true"/>
> omitNorms="true"/>
>
>
>
>stored="true" multiValued="false" required="true"/>
>multiValued="false" />
>multiValued="false" />
>stored="true" multiValued="false" />
>
> id
> name
>
>
> {code}
> Allow the trunk test to work.
> h3. Coding notes:
> The code itself refactored some of DOMUtil (the ant based property
> substitution) into one added class (PropertyMap & PropertyMap.Evaluator).
> The PropertyMap are chained (one link chain between core to multicore map);
> those maps are owned by each core's ResourceLoader.
> Config is modified a little to accommodate delaying & specializing property
> expansions.
> Multicore is modified so it properly parses & serializes.
> Tes
[jira] Issue Comment Edited: (SOLR-647) Do SolrCore.close() in a refcounted way
[
https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623204#action_12623204
]
henrib edited comment on SOLR-647 at 8/17/08 9:34 AM:
-
Small err that would affect reload() in CoreContainer.register, ~line 261, it
seems this should be:
{code}
log.info( "replacing core: "+name );
if (!returnPrev) {
old.close(); // not core.close()
}
{code}
Harmless, the "alias" attribute feature is folded into "name" so:
{code}
String aliasesStr = DOMUtil.getAttr(node, "aliases", null);
{code}
can go.
was (Author: henrib):
Small err that would affect reload() in CoreContainer.register, ~line 261, it
seems this should be:
{code}
log.info( "replacing core: "+name );
if (!returnPrev) {
old.close(); // not core.close()
}
{code}
> Do SolrCore.close() in a refcounted way
> ---
>
> Key: SOLR-647
> URL: https://issues.apache.org/jira/browse/SOLR-647
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Noble Paul
>Assignee: Yonik Seeley
> Fix For: 1.3
>
> Attachments: refcount_example.patch, solr-647.patch, solr-647.patch,
> solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch,
> solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch,
> solr-647.patch, solr-647.patch, SOLR-647.patch, SOLR-647.patch
>
>
> The method _SolrCore.close()_ directly closes the core . It can cause
> Exceptions for in-flight requests. The _close()_ method should just do a
> decrement on refcount and the actual close must happen when the last request
> being processed by that core instance is completed
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-647) Do SolrCore.close() in a refcounted way
[
https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623204#action_12623204
]
Henri Biestro commented on SOLR-647:
Small err that would affect reload() in CoreContainer.register, ~line 261, it
seems this should be:
{code}
log.info( "replacing core: "+name );
if (!returnPrev) {
old.close(); // not core.close()
}
{code}
> Do SolrCore.close() in a refcounted way
> ---
>
> Key: SOLR-647
> URL: https://issues.apache.org/jira/browse/SOLR-647
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Noble Paul
>Assignee: Yonik Seeley
> Fix For: 1.3
>
> Attachments: refcount_example.patch, solr-647.patch, solr-647.patch,
> solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch,
> solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch,
> solr-647.patch, solr-647.patch, SOLR-647.patch, SOLR-647.patch
>
>
> The method _SolrCore.close()_ directly closes the core . It can cause
> Exceptions for in-flight requests. The _close()_ method should just do a
> decrement on refcount and the actual close must happen when the last request
> being processed by that core instance is completed
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623029#action_12623029
]
henrib edited comment on SOLR-646 at 8/15/08 5:43 PM:
-
Thanks HossMan for the review;
I've overhauled the code following your comments (more focused, less code, less
public) & I'm writing more tests.
One important question: do we need or even want the "include" feature or should
I drop it (at least for now)?
Should be able to upload a "take-2" in a few days.
was (Author: henrib):
Thanks HossMan for the review;
I've overhauled the code following your comments (more focused, less code, less
public) & I'm writing more tests.
Should be able to upload a "take-2" in a few days.
> Configuration properties in multicore.xml
> -
>
> Key: SOLR-646
> URL: https://issues.apache.org/jira/browse/SOLR-646
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Ryan McKinley
> Fix For: 1.3
>
> Attachments: solr-646.patch, solr-646.patch, solr-646.patch,
> solr-646.patch
>
>
> This patch refers to 'generalized configuration properties' as specified by
> [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
> This means configuration & schema files can use expression based on
> properties defined in multicore.xml.
> h3. Use cases:
> Share the same schema and/or config file between multiple cores but point to
> different dataDirs using a ${core.datadir}
> Change the general layout between data, config & schema directories.
> Define 'installation' wide properties (for replication for instance) in
> multicore.properties (different base/install/data directories on different
> hosts).
> h3. Syntax:
> h4. Defining properties:
> Either in the multicore.properties file (usual property format):
> {code:xml}
> env.value=an installation value
> env.other_value=another installation value
> {code}
> In the multicore.xml:
> {code:xml}
>
> a value
> ${env.value} }
>
> some value
> ${mp0}-and some data
>
>
> {code}
> h4. Using properties:
> Besides used defined properties, the following core descriptor properties are
> automatically defined in each core context, namely:
> {code}
> solr.core.instanceDir
> solr.core.instancePath
> solr.core.name
> solr.core.configName
> solr.core.schemaName
> {code}
> All properties can be used in any attribute or text node of a solrconfig.xml
> or schema.xml as in:
> {code:xml}
> ${core.dataDir}
> {code}
> h4. Technical specifications
> Multicore.xml can define properties at the multicore & each core level.
> Properties defined in the multicore scope can override system properties.
> Properties defined in a core scope can override multicore & system properties.
> Property definitions can use expressions to define their name & value; these
> expressions are evaluated in their outer scope context .
> Multicore serialization keeps properties as written (ie as expressions if
> they were defined so).
> The core descriptor properties are automatically defined in each core
> context, namely:
> solr.core.instanceDir
> solr.core.instancePath
> solr.core.name
> solr.core.configName
> solr.core.schemaName
> h4. Test:
> The following (contrived) multicore.xml:
> {code:xml}
>
> 33
> 0
> 1
> bogus
> bogus
>
> core${zero}_id
> solr.DirectUpdateHandler2
> 11
>
>
> core${one}_id
> solr.DirectUpdateHandler2
> 22
>
>
> {code}
> allows this config.xml:
> {code:xml}
>
>
>
>
> multipartUploadLimitInKB="2048" />
>
>
>default="true" />
>
>class="org.apache.solr.handler.admin.LukeRequestHandler" />
>
>
>
> solr
> solrconfig.xml schema.xml admin-extra.html
>
> qt=standard&q=solrpingquery
>
>
>
> {code}
> and this schema.xml:
> {code:xml}
>
>
>
> sortMissingLast="true" omitNorms="true"/>
> omitNorms="true"/>
>
>
>
>stored="true" multiValued="false" required="true"/>
>multiValued="false" />
>multiValued="false" />
>stored="true" multiValued="false" />
>
> id
> name
>
>
> {code}
> Allow the trunk test to work.
> h3. Coding notes:
> The code itself refactored some of DOMUtil (the ant based property
> substitution) into one added class (PropertyMap & PropertyMap.Evaluator).
> The PropertyMap are chained (one link chain between core to multicore map);
> those maps are owned by each core's ResourceLoader.
> Config is modified a little to accommodate delaying & specializing property
> expansions.
> Multicore is modified so it properly parses & serializes.
> Tested against the example above.
> Reviews & comments more than welcome.
--
This me
