[
https://issues.apache.org/jira/browse/ZOOKEEPER-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717511#comment-17717511
]
Kezhu Wang commented on ZOOKEEPER-4692:
---------------------------------------
Both {{ClientCnxn.SessionTimeoutException}} and
{{ClientCnxn.SessionExpiredException}} are assistant classes. The exported one
is {{KeeperException.SessionExpiredException}}. There is no concept {{timeout}}
in ZooKeeper, but only session {{expired}}.
The {{ClientCnxn.SessionTimeoutException}} should resolves to
{{KeeperException.SessionExpiredException}} finally. But there is bug in
{{ClientCnxn.SendThread.run}}, see ZOOKEEPER-4508 for reference. I guess you
are reporting the same bug ?
> Handle SessionTimeoutException in Java client
> ---------------------------------------------
>
> Key: ZOOKEEPER-4692
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4692
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
> Affects Versions: 3.8.1
> Reporter: Giorgos Georgiou
> Priority: Minor
>
> The Java client sets a read timeout equal to 2/3 of the session timeout and
> throws a SessionTimeoutException when this is hit.
> [https://github.com/apache/zookeeper/blob/89c1831f84891f425f1fa9224210587124f1c1ec/zookeeper-server/src/main/java/org/apache/zookeeper/ClientCnxn.java#L1236-L1243]
> However, the effect of that exception is not treated the same was as a
> SessionExpiredException which is propagated to the user and is treated as a
> disconnect event instead.
> This doesn't play very well with Curator which manages its own exception
> expiry client side and starts its countdown on disconnect events, meaning
> that it will consider the session lost a whole 2/3 of the session timeout
> after it actually expired.
> Should the SessionTimeoutException also be propagated to the users for
> handling and potentially considering the session lost from their end?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
