[
https://issues.apache.org/jira/browse/ZOOKEEPER-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421698#comment-16421698
]
Antonio Rafael Rodrigues edited comment on ZOOKEEPER-3015 at 4/1/18 3:50 PM:
-----------------------------------------------------------------------------
Actually, I don't know for sure as I'm not familiarized with zookeeper's
design. But I've got some thoughts.
1 - If we introduce a new KeeperState ClientSessionTimeout, we would have to
emmit WatchedEvent(ClientSessionTimeout) instead of the
WatchedEvent(Disconnected) and there are current clients that expect
WatchedEvent(Disconnected) for the case of client session timeout.
2 - I'm thinking about some options:
a) we could add a field, some kind of EventInfo, to WatchedEvent. Of
course we'd have to come up with a way to have different information on
EventInfo, depending on the KeeperState.
b) another way would be to have a subclass of WatchedEvent, that subclass
would hold the details about the event. The clients, verifies if the
KeeperState==Disconect, if so it could make a cast of WatchedEvent to
WatchedEventDisconect and get some valueable information.
c) we could have a field with some key-value structure in WatchedEvent, so
we could add values to this field depending on the KeeperState. The client
would have to verify the KeeperState in order to know what informations are
available in the key-value structure
was (Author: arrodrigues):
Actually, I don't know for sure as I'm not familiarized with zookeeper's
design. But I've got some thoughts.
1 - If we introduce a new KeeperState ClientSessionTimeout, we would have to
emmit WatchedEvent(ClientSessionTimeout) instead of the
WatchedEvent(Disconnected) and there are current clients that expect
WatchedEvent(Disconnected) for the case of session timeout.
2 - I'm thinking about some options:
a) we could add a field, some kind of EventInfo, to WatchedEvent. Of course
we'd have to come up with a way to have different information on EventInfo,
depending on the KeeperState.
b) another way would be to have a subclass of WatchedEvent, that subclass
would hold the details about the event. The clients, verifies if the
KeeperState==Disconect, if so it could make a cast of WatchedEvent to
WatchedEventDisconect and get some valueable information.
c) we could have a field with some key-value structure in WatchedEvent, so
we could add values to this field depending on the KeeperState. The client
would have to verify the KeeperState in order to know what informations are
available in the key-value structure
> Publish the value of getIdleRecv() in WatchedEvent of Disconnected
> ------------------------------------------------------------------
>
> Key: ZOOKEEPER-3015
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3015
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
> Affects Versions: 3.5.3
> Reporter: Antonio Rafael Rodrigues
> Priority: Minor
>
> In the class ClientCnxn, at the line 1247:
> eventThread.queueEvent(new WatchedEvent(
> Event.EventType.None,
> Event.KeeperState.Disconnected,
> null));
> The current value of getIdleRecv() could be published inside the
> WatchedEvent, so that the clients that are listening to this event could know
> exactly how many time has been elapsed.
> This would be specially useful in the case of the message "Client session
> timed out, have not heard from server in " . When the client receive a
> WatchedEvent with Event.KeeperState.Disconnected, it doesn't know if it was
> due to a immediate loss of connection or a lack of heart beats. Publishing
> the value of getIdleRecv() would give a clue on that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
