[
https://issues.apache.org/jira/browse/SOLR-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15586971#comment-15586971
]
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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
