Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Zookeeper >> mail # user >> What should I do with SyncDisconnected


+
Ivan Kelly 2013-03-13, 21:01
+
Jordan Zimmerman 2013-03-13, 21:21
+
kishore g 2013-03-14, 01:51
+
Ivan Kelly 2013-03-14, 21:30
+
Jordan Zimmerman 2013-03-14, 21:43
+
Ivan Kelly 2013-03-25, 09:26
Copy link to this message
-
Re: What should I do with SyncDisconnected
Curator has its own concept of connection timeout. It's a separate value from the session timeout.

-JZ

On Mar 25, 2013, at 2:26 AM, Ivan Kelly <[EMAIL PROTECTED]> wrote:

> On Thu, Mar 14, 2013 at 02:43:58PM -0700, Jordan Zimmerman wrote:
>>> But how long to wait? If the server is truly partitioned from ZK, then
>>> I'll wait forever, and the client request will be hung forever.
>> Curator waits for the time specified as the "connection
>> timeout". Curator introduces three connection states, CONNECTED,
>> SUSPENDED and LOST. When SysDisconnected is received, Curator sets
>> the state to SUSPENDED and then issues a sync() in the
>> background. This sync() does through Curator's normal connection
>> management, retries, etc. If the sync() doesn't succeed within the
>> connection timeout, Curator sets the state to LOST. How the
>> application handles these state changes is, of course, up to the
>> app.  
> Sorry for the late reply.
>
> The connection timeout is defined in curator though? Or is taken from
> the session timeout? We're doing something like this now.
>
> -Ivan
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB