Alan Woodward commented on SOLR-9659:

bq. this is really the perfect use case to start experimenting with an 
incremental move

I've started playing with this now, but what concerns me immediately is that 
there's no way in Curator to pass in an existing ZK client.  This means that 
we'd need to maintain two client connections for every SolrZkClient instance, 
which I can see being very complex to deal with.  What happens if we get a 
socket error on one of the connections, but not the other, for example?  What 
if we start adding more security?

Don't get me wrong, I think Curator is great, and it would be cool if we could 
start to use it.  And I definitely take on board the point that it has a lot 
more eyeballs than Solr's internals.  But I think an incremental cutover will 
be very hard, and this API is such an improvement over what we have currently 
that it's worth going ahead with for now.

> 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