Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Sat, 16 Feb 2013 16:25:12 +0000 (UTC)
From: "Erick Erickson (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12379510.1191351874229.297743.1361031912335@arcas>
In-Reply-To: <JIRA.12379510.1191351874229@arcas>
References: <JIRA.12379510.1191351874229@arcas>
Subject: [jira] [Closed] (SOLR-371) trigger arbitrary events by name through
 http interface
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/SOLR-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erick Erickson closed SOLR-371.
-------------------------------

    Resolution: Won't Fix

Cleaning up old JIRAs, re-open if necessary. Exists binary type now.
                
> trigger arbitrary events by name through http interface
> -------------------------------------------------------
>
>                 Key: SOLR-371
>                 URL: https://issues.apache.org/jira/browse/SOLR-371
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Daniel Wu
>
> There are operational needs to trigger execution of some programs or scripts on any Solr instance.  For example, triggering a commit at the index transaction boundary instead of relaying on post commit hook or cron jobs, triggering snap pulling on demand or disable snap pulling, etc...
> This obviously can be done through remote script execution over ssh.  However, the client will need to have in-depth knowledge about the Solr instances it  interacts with.  The complexity incleases when there are multiple indexes and instances for the client to manage.
> If the request can be submitted through Solr HTTP interface, there can be many benefits.  It encapsulated many detail of the Solr instances to the triggering client such as the physical location of the Solr instances, machine architecture, authencation, communication channel, etc...
> Per Chris Hostetter, -- 
> The existing postCommit/postOptimizefirstSearcher/newSearcher event listener tracking are part of hte SolrCore because it needs to know about them when managing the index ... but if you just wanted a way to trigger arbitrary events by name, the utility functions used in SolrCore could be reused by a custom plugin ... then you could reuse things like the RunExecutableListener from your own RequestHandler with the same solrconfig.xml syntax.
> that would be a pretty cool addition to Solr ... an "EventRequestHandler" that takes in a single "event" param and triggers all of the Listeners configured for that even in the solrconfig.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org