[jira] [Updated] (SOLR-5200) Add REST support for reading and modifying Solr configuration
[
https://issues.apache.org/jira/browse/SOLR-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-5200:
Description:
There should be a REST API to allow full read access to, and write access to
some elements of, Solr's per-core and per-node configuration not already
covered by the Schema REST API:
{{solrconfig.xml}}/{{core.properties}}/{{solrcore.properties}} and
{{solr.xml}}/{{solr.properties}} (SOLR-4718 discusses addition of
{{solr.properties}}).
Use cases for runtime configuration modification include scripted setup,
troubleshooting, and tuning.
Tentative rules-of-thumb about configuration items that should not be
modifiable at runtime:
# Startup-only items, e.g. where to start core discovery
# Items that are deprecated in 4.X and will be removed in 5.0
# Items that if modified should be followed by a full re-index
Some issues to consider:
Persistence: How (and even whether) to handle persistence for configuration
modifications via REST API is not clear - e.g. persisting the entire config
file or having one or more sidecar config files that get persisted. The extent
of what should be modifiable will likely affect how persistence is implemented.
For example, if the only {{solrconfig.xml}} modifiable items turn out to be
plugin configurations, an alternative to full-{{solrconfig.xml}} persistence
could be individual plugin registration of runtime config modifiable items,
along with per-plugin sidecar config persistence.
Live reload: Most (if not all) per-core configuration modifications will
require core reload, though it will be a live reload, so some things won't be
modifiable, e.g. {{dataDir}} and {{IndexWriter}} related settings in
{{indexConfig}} - see SOLR-3592. (Should a full reload be supported to
handle changes in these places?)
Interpolation aka property substitution: I think it would be useful on read
access to optionally return raw values in addition to the interpolated values,
e.g. {{solr.xml}} {{hostPort}} raw value {{$\{jetty.port:8983}}} vs.
interpolated value {{8983}}. Modification requests will accept raw values -
property interpolation will be applied. At present interpolation is done once,
at parsing time, but if property value modificationmvn archetype:generate
-DgroupId=com.mkyong.core -DartifactId=ProjectName
-DarchetypeArtifactId=maven-archetype-quickstart
-DinteractiveMode=falsemvn archetype:generate -DgroupId=com.mkyong.core
-DartifactId=ProjectName
-DarchetypeArtifactId=maven-archetype-quickstart
-DinteractiveMode=falsemvn archetype:generate -DgroupId=com.mkyong.core
-DartifactId=ProjectName
-DarchetypeArtifactId=maven-archetype-quickstart
-DinteractiveMode=false is supported via the REST API, an alternative could be
to delay interpolation until values are requested; in this way, property value
modification would not trigger re-parsing the affected configuration source.
Response format: Similarly to the schema REST API, results could be returned in
XML, JSON, or any other response writer's output format.
Transient cores: How should non-loaded transient cores be handled? Simplest
thing would be to load the transient core before handling the request, just
like other requests.
Below I provide an exhaustive list of configuration items in the files in
question and indicate which ones I think could be modifiable at runtime. I
don't mean to imply that these must all be made modifiable, or for those that
are made modifiable, that they must be made so at once - a piecemeal approach
will very likely be more appropriate.
h2. {{solrconfig.xml}}
Note that XIncludes and includes via Document Entities won't survive a
modification request (assuming persistence is via overwriting the original
file).
||XPath under {{/config/}}||Should be modifiable via REST
API?||Rationale||Description||
|{{luceneMatchVersion}}|No|Modifying this should be followed by a full
re-index|Controls what version of Lucene various components of Solr adhere to|
|{{lib}}|Yes|Required for adding plugins at runtime|Contained jars available
via classloader for {{solrconfig.xml}} and {{schema.xml}}|
|{{dataDir}}|No|Not supported by live RELOAD|Holds all index data|
|{{directoryFactory}}|No|Not supported by live RELOAD|index directory factory|
|{{codecFactory}}|No|Modifying this should be followed by a full re-index|index
codec factory, per-field SchemaCodecFactory by default|
|{{schemaFactory}}|Partial|Although the class shouldn't be modifiable, it
should be possible to modify an already Managed schema's mutability|Managed or
Classic (non-mutable) schema factory|
|{{indexConfig}}|No|{{IndexWriter}}-related settings not supported by live
RELOAD|low-level indexing behavior|
|{{jmx}}|Yes| |Enables JMX if an MBeanServer is found|
|{{updateHandler@class}}|No| |Defaults to DirectUpdateHandler2|
|{{updateHandler/updateLog}}|No|
[jira] [Updated] (SOLR-5200) Add REST support for reading and modifying Solr configuration
[
https://issues.apache.org/jira/browse/SOLR-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-5200:
-
Description:
There should be a REST API to allow full read access to, and write access to
some elements of, Solr's per-core and per-node configuration not already
covered by the Schema REST API:
{{solrconfig.xml}}/{{core.properties}}/{{solrcore.properties}} and
{{solr.xml}}/{{solr.properties}} (SOLR-4718 discusses addition of
{{solr.properties}}).
Use cases for runtime configuration modification include scripted setup,
troubleshooting, and tuning.
Tentative rules-of-thumb about configuration items that should not be
modifiable at runtime:
# Startup-only items, e.g. where to start core discovery
# Items that are deprecated in 4.X and will be removed in 5.0
# Items that if modified should be followed by a full re-index
Some issues to consider:
Persistence: How (and even whether) to handle persistence for configuration
modifications via REST API is not clear - e.g. persisting the entire config
file or having one or more sidecar config files that get persisted. The extent
of what should be modifiable will likely affect how persistence is implemented.
For example, if the only {{solrconfig.xml}} modifiable items turn out to be
plugin configurations, an alternative to full-{{solrconfig.xml}} persistence
could be individual plugin registration of runtime config modifiable items,
along with per-plugin sidecar config persistence.
Live reload: Most (if not all) per-core configuration modifications will
require core reload, though it will be a live reload, so some things won't be
modifiable, e.g. {{dataDir}} and {{IndexWriter}} related settings in
{{indexConfig}} - see SOLR-3592. (Should a full reload be supported to
handle changes in these places?)
Interpolation aka property substitution: I think it would be useful on read
access to optionally return raw values in addition to the interpolated values,
e.g. {{solr.xml}} {{hostPort}} raw value {{$\{jetty.port:8983}}} vs.
interpolated value {{8983}}. Modification requests will accept raw values -
property interpolation will be applied. At present interpolation is done once,
at parsing time, but if property value modification is supported via the REST
API, an alternative could be to delay interpolation until values are requested;
in this way, property value modification would not trigger re-parsing the
affected configuration source.
Response format: Similarly to the schema REST API, results could be returned in
XML, JSON, or any other response writer's output format.
Transient cores: How should non-loaded transient cores be handled? Simplest
thing would be to load the transient core before handling the request, just
like other requests.
Below I provide an exhaustive list of configuration items in the files in
question and indicate which ones I think could be modifiable at runtime. I
don't mean to imply that these must all be made modifiable, or for those that
are made modifiable, that they must be made so at once - a piecemeal approach
will very likely be more appropriate.
h2. {{solrconfig.xml}}
Note that XIncludes and includes via Document Entities won't survive a
modification request (assuming persistence is via overwriting the original
file).
||XPath under {{/config/}}||Should be modifiable via REST
API?||Rationale||Description||
|{{luceneMatchVersion}}|No|Modifying this should be followed by a full
re-index|Controls what version of Lucene various components of Solr adhere to|
|{{lib}}|Yes|Required for adding plugins at runtime|Contained jars available
via classloader for {{solrconfig.xml}} and {{schema.xml}}|
|{{dataDir}}|No|Not supported by live RELOAD|Holds all index data|
|{{directoryFactory}}|No|Not supported by live RELOAD|index directory factory|
|{{codecFactory}}|No|Modifying this should be followed by a full re-index|index
codec factory, per-field SchemaCodecFactory by default|
|{{schemaFactory}}|Partial|Although the class shouldn't be modifiable, it
should be possible to modify an already Managed schema's mutability|Managed or
Classic (non-mutable) schema factory|
|{{indexConfig}}|No|{{IndexWriter}}-related settings not supported by live
RELOAD|low-level indexing behavior|
|{{jmx}}|Yes| |Enables JMX if an MBeanServer is found|
|{{updateHandler@class}}|No| |Defaults to DirectUpdateHandler2|
|{{updateHandler/updateLog}}|No| |Enables a transaction log, configures its
directory and synchronization|
|{{updateHandler/autoCommit}}|Yes| |Durability: enables hard autocommit,
configures max interval and whether to open a searcher afterward|
|{{updateHandler/autoSoftCommit}}|Yes| |Visibility: enables soft autocommit,
configures max interval|
|{{updateHandler/commitWithin/softCommit}}|Yes| |Whether commitWithin update
request param should trigger a soft commit instead of hard commit|
