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 Threaded View
Zookeeper >> mail # user >> Zookeeper performance


Copy link to this message
-
Re: Zookeeper performance
This sounds highly error prone to me regardless of whether or not zookeeper
can handle the load-. Why not just use a standard transaction model with a
vector clock or other timing device to detect conflicts so you don't have
to worry about a second server to talk to (zookeeper) to do an update?
On Jul 31, 2013 7:17 AM, "Baskar Duraikannu" <[EMAIL PROTECTED]>
wrote:

> Hello
>
> We are looking to use zookeeper for optimistic concurrency. Basically when
> the user saves data on a screen, we need to lock,  read to ensure that no
> one else has changed the row while user is editing data, persist data and
> unlock znode.
>
> If the app/thread does not get a lock, we may set a watch so that polling
> is avoided.
>
> Our application is write intensive certain times of the day. We may get
> about 100k requests per second.  Can zookeeper handle this volume?
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