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

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

Github user Randgalt commented on the issue:

    https://github.com/apache/curator/pull/193
  
    I'm -1 on this PR overall. The purpose of `state` internally is not to hold 
the connection state. It's to hold the started state of the instanced. Mixing 
the two is bound to cause problems. 
    
    A simpler solution would be:
    
    ```java
        private final ConnectionStateListener connectionStateListener = new 
ConnectionStateListener()
        {
            @Override
            public void stateChanged(CuratorFramework client, ConnectionState 
newState)
            {
                notifyListenerOfStateChanged(newState);
                if ( newState == ConnectionState.RECONNECTED )
                {
                    try
                    {
                        readValueAndNotifyListenersInBackground();
                    }
                    catch ( Exception e )
                    {
                        log.error("Could not read value after reconnect", e);
                    }
                }
            }
        };
    ```



> SharedValue could hold stall data when quourm membership changes
> ----------------------------------------------------------------
>
>                 Key: CURATOR-311
>                 URL: https://issues.apache.org/jira/browse/CURATOR-311
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Recipes
>    Affects Versions: 3.1.0
>         Environment: Linux
>            Reporter: Jian Fang
>
> We run a Zookeeper 3.5.1-alpha quorum on EC2 instances and the quorum members 
> could be changed, for example, one peer could be replaced by a new EC2 
> instance due to EC2 instance termination. We use Apache Curator 3.1.0 as the 
> zookeeper client. During our testing, we found the SharedValue data structure 
> could hold stall data during and after one peer is replaced and thus led to 
> the system failure. 
> We look into the SharedValue code. Seems it always returns the value from an 
> in-memory reference variable and the value is only updated by a watcher. If 
> for any reason, the watch is lost, then the value would never get a chance to 
> be updated again.
>  
> Right now, we added a connection state listener to force SharedValue to call 
> readValue(), i.e., read the data from zookeeper directly, if the connection 
> state has been changed to RECONNECTED to work around this issue.
> It would be great if this issue could be fixed in Curator directly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to