Hi Ashwin,
We have seen people wanting to have something like ZooKeeper without the
reliability of permanent storage and are willing to work with loosened
guarantees of current Zookeeper. What you mention on log files is certainly
a valid use case.
It would be great to see how much throughput yo
Hi,
In ZK, a read is handled by any server while a write is broadcasted from the
leader. If a client writes x to /X and then reads /X, is the client
guaranteed to see its own write x (what if a connection loss event happens
after the write and before the read)? Thanks,
Jun
Yes, if the client disconnects it will not accept a connection to a
server with a zxid lower than it's current zxid, which means it will
see its own previous write.
-Ivan
On 20 Jul 2010, at 17:28, Jun Rao wrote:
Hi,
In ZK, a read is handled by any server while a write is broadcasted
fro
it is still guaranteed to see its own write. when a client reconnects to
a different server, we guarantee that the new server will be at least as
up-to-date as the last server. otherwise the client would go back in
time and a lot of things would go wrong.
ben
On 07/20/2010 08:28 AM, Jun Rao w
Has anyone experimented with storing logger hierarchies in ZK? I'm looking
for a mechanism to dynamically change logger settings across a cluster of
daemons. An app that connects to all servers via JMX would solve the
problem; but we have a number of subsystems that do not run on the JVM so
It is pretty easy to keep configuration files in general in ZK and reload
them on change. Very handy some days!
On Tue, Jul 20, 2010 at 5:38 PM, wrote:
> Has anyone experimented with storing logger hierarchies in ZK? I'm looking
> for a mechanism to dynamically change logger settings across a c
On Tue, Jul 20, 2010 at 6:07 PM, Ted Dunning wrote:
>
> It is pretty easy to keep configuration files in general in ZK and reload
> them on change. Very handy some days!
We recently open-sourced tool to handle stuff like config reloads,
triggering actions, etc:
http://github.com/twitter/twi
Hi Mahadev, I'd love to but I don't have access to server class machines at
home/personal time.
Let me see if I can squeeze in some time to get something to run on EC2. I
need to learn how to do that first. Will certainly let you know if/when I
can get this done in my personal time.
So far, all
Hi folks,
I was considering using Zookeeper to implement a replication protocol due
the global order guarantee. In my case, operations are logged by creating
persistent sequential znodes. Knowing the name of last applied znode,
backups can identify pending operations and apply them in order. Becau
Creating a new znode for each update isn't really necessary. Just create a
file that will contain all of the updates for the next snapshot and do
atomic updates to add to the list of updates belonging to that snapshot.
When you complete the snapshot, you will create a new file. After a time
you
Travis,
Thanks for the tip. i'll take a look.
On Tue, Jul 20, 2010 at 9:35 PM, Travis Crawford
wrote:
> On Tue, Jul 20, 2010 at 6:07 PM, Ted Dunning
> wrote:
> >
> > It is pretty easy to keep configuration files in general in ZK and reload
> > them on change. Very handy some days!
>
> We rece
Ted, just to clarify. By file you mean znode, right ? So you are advising me
to try an atomic append to znode's by first calling getData and then trying
to conditionally set the data by using the version information obtained in
the previous step ?
Thanks,
André
On Tue, Jul 20, 2010 at 23:52, Ted
I did try a quick test on Windows (yes, some of us use Windows :)
I thought simply changing the "dataDir" to the "/dev/null" equivalent on
Windows would do the trick. It didn't work. It looks like a Java issue
because I noticed inconsistencies in the File API regarding this. I wrote
about it here
Not having a datadir is currently not possible - the servers expect to
read/write snapshot and log files. In particular the leader needs to be
able to stream updates, and in some cases the entire latest snapshot, to
a follower. It does this by streaming data directly from the filesystem.
Patri
14 matches
Mail list logo
