You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Nicolas Pastorino (JIRA)" <ji...@apache.org> on 2009/05/06 14:34:30 UTC
[jira] Created: (SOLR-1147) QueryElevationComponent : updating
elevate.xml through HTTP
QueryElevationComponent : updating elevate.xml through HTTP
-----------------------------------------------------------
Key: SOLR-1147
URL: https://issues.apache.org/jira/browse/SOLR-1147
Project: Solr
Issue Type: Improvement
Affects Versions: 1.3, 1.4, 1.5
Environment: Any
Reporter: Nicolas Pastorino
Priority: Minor
If one wants to update the configuration file for the QueryElevationComponent, direct edition of the file is mandatory. Currently the process seems to be :
# Replace elevate.xml in Solr's dataDir
# Commit. It appears that when having elevate.xml in Solr's dataDir, and solely in this case, commiting triggers a reload of elevate.xml. This does not happen when elevate.xml is stored in Solr's conf dir.
As a system using Solr, i would find handy to be able to push an updated elevate.xml file/XML through HTTP, with an automatic reload of it. This would remove the currently mandatory requirement of having a direct access to the elevate.xml file, allowing more distributed architectures. This would also increase the Query Elevation system's added value by making it dynamic, configuration-wise.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1147) QueryElevationComponent : updating
elevate.xml through HTTP
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710315#action_12710315 ]
Noble Paul commented on SOLR-1147:
----------------------------------
I guess a plain RequestHandler should do.
backup can be an option. the replicationHandler already does that. you can rename the old file as file-name.yyyyMMddhhmmss .
> QueryElevationComponent : updating elevate.xml through HTTP
> -----------------------------------------------------------
>
> Key: SOLR-1147
> URL: https://issues.apache.org/jira/browse/SOLR-1147
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3, 1.4, 1.5
> Environment: Any
> Reporter: Nicolas Pastorino
> Priority: Minor
> Attachments: QueryElevationAdministrationRequestHandler.java, QueryElevationAdministrationRequestHandler.java
>
>
> If one wants to update the configuration file for the QueryElevationComponent, direct edition of the file is mandatory. Currently the process seems to be :
> # Replace elevate.xml in Solr's dataDir
> # Commit. It appears that when having elevate.xml in Solr's dataDir, and solely in this case, commiting triggers a reload of elevate.xml. This does not happen when elevate.xml is stored in Solr's conf dir.
> As a system using Solr, i would find handy to be able to push an updated elevate.xml file/XML through HTTP, with an automatic reload of it. This would remove the currently mandatory requirement of having a direct access to the elevate.xml file, allowing more distributed architectures. This would also increase the Query Elevation system's added value by making it dynamic, configuration-wise.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1147) QueryElevationComponent : updating
elevate.xml through HTTP
Posted by "Otis Gospodnetic (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12709241#action_12709241 ]
Otis Gospodnetic commented on SOLR-1147:
----------------------------------------
I'm +1 for the idea of being able to push elevate config (and really other config files, too!) from a remote system into Solr.
I only skimmed the patch.
It would be good to add a unit test. Could you do that?
You'll also want to add the ASL on top of the source code. It may also be good to remove eZ publish references from the Javadoc (having that in the javadoc doesn't really help developers using Solr)
Is that "" at the end of QueryElevationAdministrationRequestHandler.class + "" really needed?
Please note the bit about the code formatting here:
http://wiki.apache.org/solr/HowToContribute#head-59ae13df098fbdcc46abdf980aa8ee76d3ee2e3b
Thanks!
> QueryElevationComponent : updating elevate.xml through HTTP
> -----------------------------------------------------------
>
> Key: SOLR-1147
> URL: https://issues.apache.org/jira/browse/SOLR-1147
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3, 1.4, 1.5
> Environment: Any
> Reporter: Nicolas Pastorino
> Priority: Minor
> Attachments: QueryElevationAdministrationRequestHandler.java, QueryElevationAdministrationRequestHandler.java
>
>
> If one wants to update the configuration file for the QueryElevationComponent, direct edition of the file is mandatory. Currently the process seems to be :
> # Replace elevate.xml in Solr's dataDir
> # Commit. It appears that when having elevate.xml in Solr's dataDir, and solely in this case, commiting triggers a reload of elevate.xml. This does not happen when elevate.xml is stored in Solr's conf dir.
> As a system using Solr, i would find handy to be able to push an updated elevate.xml file/XML through HTTP, with an automatic reload of it. This would remove the currently mandatory requirement of having a direct access to the elevate.xml file, allowing more distributed architectures. This would also increase the Query Elevation system's added value by making it dynamic, configuration-wise.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1147) QueryElevationComponent : updating
elevate.xml through HTTP
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710263#action_12710263 ]
Noble Paul commented on SOLR-1147:
----------------------------------
Pushing conf files into Solr is fine. But doing it just for QueryElevationComponent is probably not a good idea.
> QueryElevationComponent : updating elevate.xml through HTTP
> -----------------------------------------------------------
>
> Key: SOLR-1147
> URL: https://issues.apache.org/jira/browse/SOLR-1147
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3, 1.4, 1.5
> Environment: Any
> Reporter: Nicolas Pastorino
> Priority: Minor
> Attachments: QueryElevationAdministrationRequestHandler.java, QueryElevationAdministrationRequestHandler.java
>
>
> If one wants to update the configuration file for the QueryElevationComponent, direct edition of the file is mandatory. Currently the process seems to be :
> # Replace elevate.xml in Solr's dataDir
> # Commit. It appears that when having elevate.xml in Solr's dataDir, and solely in this case, commiting triggers a reload of elevate.xml. This does not happen when elevate.xml is stored in Solr's conf dir.
> As a system using Solr, i would find handy to be able to push an updated elevate.xml file/XML through HTTP, with an automatic reload of it. This would remove the currently mandatory requirement of having a direct access to the elevate.xml file, allowing more distributed architectures. This would also increase the Query Elevation system's added value by making it dynamic, configuration-wise.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1147) QueryElevationComponent : updating
elevate.xml through HTTP
Posted by "Nicolas Pastorino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nicolas Pastorino updated SOLR-1147:
------------------------------------
Attachment: QueryElevationAdministrationRequestHandler.java
This is an updated version of the one initially attached to this issue.
Following advises received on the solr-user ML ( thread : "QueryElevationComponent : hot update of elevate.xml" ), the new version is replication-proof.
> QueryElevationComponent : updating elevate.xml through HTTP
> -----------------------------------------------------------
>
> Key: SOLR-1147
> URL: https://issues.apache.org/jira/browse/SOLR-1147
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3, 1.4, 1.5
> Environment: Any
> Reporter: Nicolas Pastorino
> Priority: Minor
> Attachments: QueryElevationAdministrationRequestHandler.java, QueryElevationAdministrationRequestHandler.java
>
>
> If one wants to update the configuration file for the QueryElevationComponent, direct edition of the file is mandatory. Currently the process seems to be :
> # Replace elevate.xml in Solr's dataDir
> # Commit. It appears that when having elevate.xml in Solr's dataDir, and solely in this case, commiting triggers a reload of elevate.xml. This does not happen when elevate.xml is stored in Solr's conf dir.
> As a system using Solr, i would find handy to be able to push an updated elevate.xml file/XML through HTTP, with an automatic reload of it. This would remove the currently mandatory requirement of having a direct access to the elevate.xml file, allowing more distributed architectures. This would also increase the Query Elevation system's added value by making it dynamic, configuration-wise.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1147) QueryElevationComponent : updating
elevate.xml through HTTP
Posted by "Nicolas Pastorino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nicolas Pastorino updated SOLR-1147:
------------------------------------
Attachment: QueryElevationAdministrationRequestHandler.java
The attached RequestHandler could be a solution to the problematic presented above. Please note that the API usage may be awkward, as well as the way Java is leveraged. That's my first Solr extension :) And yes, there are quite a few unresolved things, spottable through the _'TODO'_ and _'FIXME'_ annotations.
It was tested against Solr's trunk, and seems to be working. The new Elevate configuration is to be passed, as an XML string, in the "elevate-configuration" request parameter.
> QueryElevationComponent : updating elevate.xml through HTTP
> -----------------------------------------------------------
>
> Key: SOLR-1147
> URL: https://issues.apache.org/jira/browse/SOLR-1147
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3, 1.4, 1.5
> Environment: Any
> Reporter: Nicolas Pastorino
> Priority: Minor
> Attachments: QueryElevationAdministrationRequestHandler.java
>
>
> If one wants to update the configuration file for the QueryElevationComponent, direct edition of the file is mandatory. Currently the process seems to be :
> # Replace elevate.xml in Solr's dataDir
> # Commit. It appears that when having elevate.xml in Solr's dataDir, and solely in this case, commiting triggers a reload of elevate.xml. This does not happen when elevate.xml is stored in Solr's conf dir.
> As a system using Solr, i would find handy to be able to push an updated elevate.xml file/XML through HTTP, with an automatic reload of it. This would remove the currently mandatory requirement of having a direct access to the elevate.xml file, allowing more distributed architectures. This would also increase the Query Elevation system's added value by making it dynamic, configuration-wise.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1147) QueryElevationComponent : updating
elevate.xml through HTTP
Posted by "Nicolas Pastorino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710312#action_12710312 ]
Nicolas Pastorino commented on SOLR-1147:
-----------------------------------------
Simpler, indeed. Lower-level.
Should some versioning and/or backup on configuration files be implemented too ?
On the software-design part of it : should this be a plain requestHandler ?
I propose myself for being the "little hands" coding this, if this is acceptable for all of you, after all design points are sorted out of course.
> QueryElevationComponent : updating elevate.xml through HTTP
> -----------------------------------------------------------
>
> Key: SOLR-1147
> URL: https://issues.apache.org/jira/browse/SOLR-1147
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3, 1.4, 1.5
> Environment: Any
> Reporter: Nicolas Pastorino
> Priority: Minor
> Attachments: QueryElevationAdministrationRequestHandler.java, QueryElevationAdministrationRequestHandler.java
>
>
> If one wants to update the configuration file for the QueryElevationComponent, direct edition of the file is mandatory. Currently the process seems to be :
> # Replace elevate.xml in Solr's dataDir
> # Commit. It appears that when having elevate.xml in Solr's dataDir, and solely in this case, commiting triggers a reload of elevate.xml. This does not happen when elevate.xml is stored in Solr's conf dir.
> As a system using Solr, i would find handy to be able to push an updated elevate.xml file/XML through HTTP, with an automatic reload of it. This would remove the currently mandatory requirement of having a direct access to the elevate.xml file, allowing more distributed architectures. This would also increase the Query Elevation system's added value by making it dynamic, configuration-wise.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1147) QueryElevationComponent : updating
elevate.xml through HTTP
Posted by "Nicolas Pastorino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710285#action_12710285 ]
Nicolas Pastorino commented on SOLR-1147:
-----------------------------------------
It indeed sounds like a potentially more generic feature. Should this end-up in dedicated request Handler, which receives as parameters :
* the name of the concerned searchComponent, or other 'module' using a configuration file
* the updated configuration
And passes along the updated configuration to the concerned 'module' in some way ? Should an existing interface be extended in order to comprize the necessary methods, or should this be handled with inheritance here, an abstract class presenting the 'updateConfiguration( ... )' method ? There probably are quite a few other approaches on this.
Thanks for your participation to this !
> QueryElevationComponent : updating elevate.xml through HTTP
> -----------------------------------------------------------
>
> Key: SOLR-1147
> URL: https://issues.apache.org/jira/browse/SOLR-1147
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3, 1.4, 1.5
> Environment: Any
> Reporter: Nicolas Pastorino
> Priority: Minor
> Attachments: QueryElevationAdministrationRequestHandler.java, QueryElevationAdministrationRequestHandler.java
>
>
> If one wants to update the configuration file for the QueryElevationComponent, direct edition of the file is mandatory. Currently the process seems to be :
> # Replace elevate.xml in Solr's dataDir
> # Commit. It appears that when having elevate.xml in Solr's dataDir, and solely in this case, commiting triggers a reload of elevate.xml. This does not happen when elevate.xml is stored in Solr's conf dir.
> As a system using Solr, i would find handy to be able to push an updated elevate.xml file/XML through HTTP, with an automatic reload of it. This would remove the currently mandatory requirement of having a direct access to the elevate.xml file, allowing more distributed architectures. This would also increase the Query Elevation system's added value by making it dynamic, configuration-wise.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1147) QueryElevationComponent : updating
elevate.xml through HTTP
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710612#action_12710612 ]
Noble Paul commented on SOLR-1147:
----------------------------------
bq.it may make sense to edit and rename/redescribe this issue
+1
> QueryElevationComponent : updating elevate.xml through HTTP
> -----------------------------------------------------------
>
> Key: SOLR-1147
> URL: https://issues.apache.org/jira/browse/SOLR-1147
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3, 1.4, 1.5
> Environment: Any
> Reporter: Nicolas Pastorino
> Priority: Minor
> Attachments: QueryElevationAdministrationRequestHandler.java, QueryElevationAdministrationRequestHandler.java
>
>
> If one wants to update the configuration file for the QueryElevationComponent, direct edition of the file is mandatory. Currently the process seems to be :
> # Replace elevate.xml in Solr's dataDir
> # Commit. It appears that when having elevate.xml in Solr's dataDir, and solely in this case, commiting triggers a reload of elevate.xml. This does not happen when elevate.xml is stored in Solr's conf dir.
> As a system using Solr, i would find handy to be able to push an updated elevate.xml file/XML through HTTP, with an automatic reload of it. This would remove the currently mandatory requirement of having a direct access to the elevate.xml file, allowing more distributed architectures. This would also increase the Query Elevation system's added value by making it dynamic, configuration-wise.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1147) QueryElevationComponent : updating
elevate.xml through HTTP
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710293#action_12710293 ]
Noble Paul commented on SOLR-1147:
----------------------------------
what it would probably need are
* the name of the file
and the handler can save it in the conf dir. It does not have to know which component this file belong to.
> QueryElevationComponent : updating elevate.xml through HTTP
> -----------------------------------------------------------
>
> Key: SOLR-1147
> URL: https://issues.apache.org/jira/browse/SOLR-1147
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3, 1.4, 1.5
> Environment: Any
> Reporter: Nicolas Pastorino
> Priority: Minor
> Attachments: QueryElevationAdministrationRequestHandler.java, QueryElevationAdministrationRequestHandler.java
>
>
> If one wants to update the configuration file for the QueryElevationComponent, direct edition of the file is mandatory. Currently the process seems to be :
> # Replace elevate.xml in Solr's dataDir
> # Commit. It appears that when having elevate.xml in Solr's dataDir, and solely in this case, commiting triggers a reload of elevate.xml. This does not happen when elevate.xml is stored in Solr's conf dir.
> As a system using Solr, i would find handy to be able to push an updated elevate.xml file/XML through HTTP, with an automatic reload of it. This would remove the currently mandatory requirement of having a direct access to the elevate.xml file, allowing more distributed architectures. This would also increase the Query Elevation system's added value by making it dynamic, configuration-wise.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1147) Updating configuration files through
HTTP
Posted by "Nicolas Pastorino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nicolas Pastorino updated SOLR-1147:
------------------------------------
Description:
*Current behaviour* :
If one wants to update a configuration file placed in Solr's conf dir, direct edition of the file is mandatory. Currently the process is :
# Replace the concerned configuration file in Solr's conf dir
# Commit.
A commit triggers a reload of the configurations files, as long as their associated components are registered to this event. This can be achieved for a searchComponent as follows :
{noformat}
<str name="refreshOnCommmit">true</str>
{noformat}
_Side question : how to register other types of components to the commit event ?_
*Use case* :
As a system using Solr, i would find handy to be able to push an updated configuration file through HTTP.
This would remove the currently mandatory requirement of having a direct access to configuration files, allowing more distributed architectures. This would also increase the components' added value by making them dynamic, configuration-wise.
*Possible design* :
A new requestHandler, taking as parameter :
* the name of the file to update
* optionnally if a backup of the previous version of the file is to be done ( cf replicationHandler )
*Open questions* :
* Should reloading the new configuration keep using the "reload on commit" feature ?
was:
If one wants to update the configuration file for the QueryElevationComponent, direct edition of the file is mandatory. Currently the process seems to be :
# Replace elevate.xml in Solr's dataDir
# Commit. It appears that when having elevate.xml in Solr's dataDir, and solely in this case, commiting triggers a reload of elevate.xml. This does not happen when elevate.xml is stored in Solr's conf dir.
As a system using Solr, i would find handy to be able to push an updated elevate.xml file/XML through HTTP, with an automatic reload of it. This would remove the currently mandatory requirement of having a direct access to the elevate.xml file, allowing more distributed architectures. This would also increase the Query Elevation system's added value by making it dynamic, configuration-wise.
Summary: Updating configuration files through HTTP (was: QueryElevationComponent : updating elevate.xml through HTTP)
> Updating configuration files through HTTP
> -----------------------------------------
>
> Key: SOLR-1147
> URL: https://issues.apache.org/jira/browse/SOLR-1147
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3, 1.4, 1.5
> Environment: Any
> Reporter: Nicolas Pastorino
> Priority: Minor
> Attachments: QueryElevationAdministrationRequestHandler.java, QueryElevationAdministrationRequestHandler.java
>
>
> *Current behaviour* :
> If one wants to update a configuration file placed in Solr's conf dir, direct edition of the file is mandatory. Currently the process is :
> # Replace the concerned configuration file in Solr's conf dir
> # Commit.
> A commit triggers a reload of the configurations files, as long as their associated components are registered to this event. This can be achieved for a searchComponent as follows :
> {noformat}
> <str name="refreshOnCommmit">true</str>
> {noformat}
> _Side question : how to register other types of components to the commit event ?_
> *Use case* :
> As a system using Solr, i would find handy to be able to push an updated configuration file through HTTP.
> This would remove the currently mandatory requirement of having a direct access to configuration files, allowing more distributed architectures. This would also increase the components' added value by making them dynamic, configuration-wise.
> *Possible design* :
> A new requestHandler, taking as parameter :
> * the name of the file to update
> * optionnally if a backup of the previous version of the file is to be done ( cf replicationHandler )
> *Open questions* :
> * Should reloading the new configuration keep using the "reload on commit" feature ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1147) QueryElevationComponent : updating
elevate.xml through HTTP
Posted by "Otis Gospodnetic (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710397#action_12710397 ]
Otis Gospodnetic commented on SOLR-1147:
----------------------------------------
Nicolas - I think it may make sense to edit and rename/redescribe this issue now, if you are going to make this more generic.
> QueryElevationComponent : updating elevate.xml through HTTP
> -----------------------------------------------------------
>
> Key: SOLR-1147
> URL: https://issues.apache.org/jira/browse/SOLR-1147
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3, 1.4, 1.5
> Environment: Any
> Reporter: Nicolas Pastorino
> Priority: Minor
> Attachments: QueryElevationAdministrationRequestHandler.java, QueryElevationAdministrationRequestHandler.java
>
>
> If one wants to update the configuration file for the QueryElevationComponent, direct edition of the file is mandatory. Currently the process seems to be :
> # Replace elevate.xml in Solr's dataDir
> # Commit. It appears that when having elevate.xml in Solr's dataDir, and solely in this case, commiting triggers a reload of elevate.xml. This does not happen when elevate.xml is stored in Solr's conf dir.
> As a system using Solr, i would find handy to be able to push an updated elevate.xml file/XML through HTTP, with an automatic reload of it. This would remove the currently mandatory requirement of having a direct access to the elevate.xml file, allowing more distributed architectures. This would also increase the Query Elevation system's added value by making it dynamic, configuration-wise.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.