Scott Blum commented on SOLR-9659:

+1 this is really the perfect use case to start experimenting with an 
incremental move.  I think long term that Curator is a really good idea.  I 
took a quick look at your patch and it makes me sad imagining the cycle of 
review, bug discovery, fix etc that would ultimately have to happen when 
there's already code that handles so much of that subtlety, including issues 
around re-entrant code, data races, threading, etc.

> Add zookeeper DataWatch API
> ---------------------------
>                 Key: SOLR-9659
>                 URL: https://issues.apache.org/jira/browse/SOLR-9659
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Alan Woodward
>            Assignee: Alan Woodward
>         Attachments: SOLR-9659.patch
> We have several components which need to set up watches on ZooKeeper nodes 
> for various aspects of cluster management.  At the moment, all of these 
> components do this themselves, leading to large amounts of duplicated code, 
> and complicated logic for dealing with reconnections, etc, scattered across 
> the codebase.  We should replace this with a simple API controlled by 
> SolrZkClient, which should make the code more robust, and testing 
> considerably easier.

This message was sent by Atlassian JIRA

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

Reply via email to