[
https://issues.apache.org/jira/browse/SOLR-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690629#comment-17690629
]
David Smiley commented on SOLR-6405:
------------------------------------
(8.5 years later) I think I'm missing an important concept here. If a
SessionExpiredException happens, why don't we retry, just as we do with
ConnectionLossException? Looking at Curator (for inspiration / clues),
SessionFailRetryLoop documents that the _standard_ retry loop (which isn't
SessionFailRetryLoop BTW) treats the two exceptions equivalently, implying this
is usually what you want. But that a session failure will result in loss of
ephemeral nodes by this client (i.e. may no longer be a leader, say). In
general, we may not know what the caller of retryOperation wants. Something
simple like REQUESTSTATUS could throw session expiration but it's really
ignorable (ideally would have retried). I've seen this. On the other hand,
_perhaps_ a leader oriented process may want otherwise – I'm not sure on that.
That's why I'm asking here.
> ZooKeeper calls can easily not be retried enough on ConnectionLoss.
> -------------------------------------------------------------------
>
> Key: SOLR-6405
> URL: https://issues.apache.org/jira/browse/SOLR-6405
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: Mark Miller
> Assignee: Mark Miller
> Priority: Critical
> Fix For: 4.10, 6.0
>
> Attachments: SOLR-6405.patch
>
>
> The current design requires that we are sure we retry on connection loss
> until session expiration.
--
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
