[jira] [Comment Edited] (ZOOKEEPER-3015) Publish the value of getIdleRecv() in WatchedEvent of Disconnected

["Antonio Rafael Rodrigues (JIRA)" <ji...@apache.org>]

    [ 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)