[
https://issues.apache.org/jira/browse/SOLR-17702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935553#comment-17935553
]
Houston Putman commented on SOLR-17702:
---------------------------------------
So what you mentioned at
[https://github.com/apache/curator/pull/514#discussion_r1887528639] and what
I'm mentioning here are very similar, but ultimately not related.
That PR relates to the watches executor, which I am very much not touching here
(This PR will not affect watches on nodes at all). This is the
connectionStateListenerExecutor, which does act as a watch, but from my
investigation in Curator, does not go through the same {{NamespaceWatcher}}
code-path that the node watcher logic goes through.
The shutdown logic ordering discussion is also very similar, and after thinking
about it a bit more, we probably don't need to be executing node watches after
shutdown either. But I would prefer that to live in another PR as well. Keep
things nice and tidy. (And could ultimately come with a full-scale re-doing of
how we think about async watch execution)
> ZkController should own its own reconnect logic
> -----------------------------------------------
>
> Key: SOLR-17702
> URL: https://issues.apache.org/jira/browse/SOLR-17702
> Project: Solr
> Issue Type: Improvement
> Affects Versions: main (10.0)
> Reporter: Houston Putman
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since we use Curator now, the SolrZkClient is no longer in charge of
> maintaining onDisconnect and onReconnect listeners, Curator does. This means
> that SolrZkClient doesn't need to own their execution either.
> ZkController is the main usage of this logic, with big "onDisconnect" and
> "onReconnect" methods. However, when onReconnect is called just before a
> server is taken down, the ZkController does not own the executor for this
> reconnect logic, so we have to wait until the SolrZkClient is shut down (one
> of the last steps of shutting down a solr node).
> Instead, we can have the ZkController take control of the executor, so that
> we can ensure that reconnect and disconnect logic is stopped once "close()"
> is called.
> There are a few other places that use the SolrZkClient onReconnect()
> listener, but those can be transitioned to call Curator to add them.
> (ZkStateReader being the main one). And this is only going to go to main
> (10.0) since it requires Curator, so we don't need to worry about changing
> class/method signatures or back-compatibility.
> And one extra benefit is that we are slimming down one more thing from
> SolrZkClient (and maybe we can actually retire it one day)!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
