[
https://issues.apache.org/jira/browse/SOLR-17702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman resolved SOLR-17702.
-----------------------------------
Fix Version/s: main (10.0)
Assignee: Houston Putman
Resolution: Fixed
> 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
> Assignee: Houston Putman
> Priority: Major
> Labels: pull-request-available
> Fix For: main (10.0)
>
> Time Spent: 0.5h
> 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
