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 # dev >> Re: Timeouts and ping handling


+
Camille Fournier 2012-01-18, 22:03
+
Patrick Hunt 2012-01-18, 22:45
Copy link to this message
-
Re: Timeouts and ping handling
Duh, I knew there was something I was forgetting. You can't process the
session timeout faster than the server can process the full pipeline, so
making pings come back faster just means you will have a false sense of
liveness for your services.

The question about why the leaders and followers handle read-only requests
differently still stands, though.

C

On Wed, Jan 18, 2012 at 5:45 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:

> On Wed, Jan 18, 2012 at 2:03 PM, Camille Fournier <[EMAIL PROTECTED]>
> wrote:
> > I think it can be done. Looking through the code, it seems like it should
> > be safe modulo some stats that are set in the FinalRequestProcessor that
> > may be less useful.
> >
>
> Turning around HBs at the head end of the server is a bad idea. If the
> server can't support the timeout you requested then you are setting
> yourself up for trouble if you try to fake it. (think through some of
> the failure cases...)
>
> This is not something you want to do. Rather first look at some of the
> more obvious issues such as GC, then disk (I've seen ppl go to
> ramdisks in some cases), then OS/net tuning etc....
>
> Patrick
>
+
Patrick Hunt 2012-01-19, 01:38
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