Alan Woodward commented on SOLR-9659:

Aha, hadn't spotted the *Cache objects.  Yes, I can see they're trying to do 
the same thing.  And I like the ability to pass in an Executor for running the 
callbacks as well; I'll extend the patch to add that ability.

My reservation about going directly to Curator would be that I don't think we 
want to be maintaining two different frameworks at the same time.  Instead, I'd 
suggest we gradually hide all the ZK interaction behind some nicer APIs in 
SolrZkClient, and then we can swap in Curator behind that single point.

> 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