I thought that most of the ledger metadata was managed by the clients. In any
case, if ledgers aren't replicated, then I don't see the need of managing any
metadata, especially if the bookie is embedded. The problem is that we lose of
the semantic properties, like we won't be able to close a led
Well, zookeeper is used for two parts: one is metadata storage, while the
other one is bookie discovery. so it is easy to disable zookeeper for
bookie discovery as it will talk to a local bookie node, while it is
difficult to disable zookeeper for metadata storage. That's why I was
thinking of intr
Oggetto: Re: Bookkeeper and VM-local transport
It should be possible to turn off all ZK-related functionality in a bookie, no?
The role of the bookie is simply to write ledger fragments and all ZK-related
access should be orthogonal to that, and if I'm right, then we could have a
flag
It should be possible to turn off all ZK-related functionality in a bookie, no?
The role of the bookie is simply to write ledger fragments and all ZK-related
access should be orthogonal to that, and if I'm right, then we could have a
flag that disables all ZK accesses.
-Flavio
> On 18 Feb 201
This seems to be a very interesting idea. I think there is way to change
bookkeeper to do that. But I am not sure about zookeeper as that is a black
box to bookkeeper. For unit testing, I could think of making a
local/in-memory ledger manager to mock out zookeeper. But yes, that is a
very useful fe
Hi,
I'm wondering if it is feasible to have a way to launch a Bookie and a
Bookkeeper client in the same JVM without using network, valid use cases are:
1) Unit testing
2) Installations using a single Bookie
1) Unit testing
For unit testing I'm using mock classes which reproduce the functions
