[ 
https://issues.apache.org/jira/browse/CURATOR-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16433068#comment-16433068
 ] 

ASF GitHub Bot commented on CURATOR-460:
----------------------------------------

Github user cammckenzie commented on the issue:

    https://github.com/apache/curator/pull/262
  
    My issue is the difference in timing in these events:
    -If the connection between client and server is lost a disconnected event 
is received essentially immediately.
    -If a heart beat is missed it takes 2/3 of the session timeout.
    
    So, we can't reliably do anything with timers because we can't tell the 
difference between these two events. In the first case, ideally, we would 
inject a LOST event after the negotiated session timeout MS. In the second 
case, ideally, we would inject a LOST event after 1/3 of the negotiated session 
timeout MS.
    
    For a short session timeout the difference is minimal, but for a longer 
session timeout, it will be significant. I guess all we can do is the approach 
that we already have where the client of the Curator library can decide what % 
of the session timeout they want to use before a session timeout is injected. I 
would think that in general, connection loss is more likely than missed heart 
beats, so maybe we should just leave the default % of session timeout as it is 
at 100% as this will be correct for the most likely case.


> Timed tolerance for connection suspended leads to simultaneous leaders
> ----------------------------------------------------------------------
>
>                 Key: CURATOR-460
>                 URL: https://issues.apache.org/jira/browse/CURATOR-460
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Recipes
>    Affects Versions: 3.3.0, 4.0.0, 4.0.1
>            Reporter: Antonio Rafael Rodrigues
>            Assignee: Cameron McKenzie
>            Priority: Major
>         Attachments: ConnectionStateManager.patch, 
> Console-leaderSelector1.log, Console-leaderSelector2.log, 
> CuratorLeaderSelectorPOC.java, LogApp1.log, LogApp2.log
>
>
> Starting from Curator 3, after losing the connection to zookeeper, curator 
> emits a SUSPENDED event and then starts an internal timer, if the time of the 
> negotiatied session timeout get hit and curator didn't reconnect to zookeeper 
> it emits a LOST event.
> For example :
>  Given negotiated session timeout = 40
> ||Time (seconds)||Event||
> |0|SUSPENDED (curator has been disconnected from zookeeper)|
> |40|LOST (curator is still disconnected, it must have been lost the sesion as 
> it is disconnected for 40sec)|
> Given this scenario we could ,theoretically, ignore the SUSPENDED event and 
> consider the leadership as lost just if the ConnectionStateListener receives 
> the LOST event.
> But this feature seems to have introduced a bug (from my point of view)
> *Case of failure*
> ||Time (seconds)||Event||
> |0|Something went wrong with the connected zookeeper (in my case, the network 
> inteface of zookeeper's server has gone down). Curator stops hearing heart 
> beats from zookeeper, but doesn't lose the connection (from some reason that 
> I don't know, if the network interface of the server goes down, Curator 
> doesn't lose the connection)|
> |~26.666|SUSPENDED (after 26 seconds without hearing heartbeats, curator 
> emits a SUSPENDED event) 26 is from "readTimeout = sessionTimeout * 2 / 3" 
> from the class ClientCnxn.java from zookeeper client. At this point, curator 
> starts counting 40 sec.|
> |26.666 to 40|During this period, Curator is trying to connect to other 
> zookeeper instances but the other instances, in my example case, are also 
> uncheachable.|
> |40|Session has expired and the other instance has taken leadership ( in my 
> example, the other instance can connect to zookeeper )|
> |66.666|LOST ( after 40sec from SUSPENDED, curator finally sends LOST)|
> As you can see, if we are ignoring the SUSPENDED event, the second 
> application instance acquires the leadership ~26 seconds before the first 
> instance notice that it lost the leadership.
>  I understand it seems to be a very rare case, but either way I think it 
> should be addressed.
> *Reproduce it*
> I have came up with a way to reproduce this easily. I know this is not a 
> recommended production setup, but it reproduces the problem anyway.
> 1) On a virtual machine, with 2 network interfaces (eth0[192.168.0.101], 
> eth1[192.168.0.102]) , I installed one zookeeper instance.
>  2) I setup application1 with the leadership receipe, with 40sec of 
> negotiated timeout, pointing just to 192.168.0.101  .Now it is the leader
>  3) I setup application2 with the leadership receipe, with 40sec of 
> negotiated timeout, pointing just to 192.168.0.102  .Now it it is NOT the 
> leader
>  4) On the server I turn the eth0[192.168.0.101] interface down  [ ifconfig 
> eth0 down ]
>  5) After 26 seconds, application1 says : 
>            :ClientCnxn$SendThread@1111] - Client session timed out, have not 
> heard from server in 26679ms for sessionid
>             ConnectionStateManager@237] - State change: SUSPENDED
>         NOTE: I'm ignoring the SUSPENDED event
> 6) After 40 seconds, application2 takes leadership
>  7) After 66 seconds, application1 says :
>              ConnectionStateManager@237] - State change: LOST
>          
>          NOTE: Just at this point, I consider that the application1 has lost 
> leadership
> Then, for 26 seconds, we had 2 leaders.
> If you confirm it as a bug, I think I could help.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to