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 ledger, but that might not be necessary for this use case.
-Flavio > On 19 Feb 2016, at 17:33, Sijie Guo <si...@apache.org> wrote: > > 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 introducing a local ledger metadata manager for such > installations. > > - Sijie > > On Thu, Feb 18, 2016 at 3:10 PM, Flavio Junqueira <f...@apache.org> wrote: > >> 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 2016, at 22:18, Sijie Guo <si...@apache.org> wrote: >>> >>> 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 feature. +1 on that. Could you file a JIRA and input your >>> proposals there? >>> >>> - Sijie >>> >>> On Thu, Feb 18, 2016 at 8:02 AM, Enrico Olivelli - Diennea < >>> enrico.olive...@diennea.com> wrote: >>> >>>> 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 >> of >>>> Bookkeeper but it makes my code more complex. >>>> Running network-related libraries limits the possibility of running >> tests >>>> in parallel and slows down the overall throughput of the tests >>>> >>>> 2) Single Bookie deployment >>>> Sometimes I need to launch software which uses Bookkeeper in a >>>> single-machine deployment, in this case using an embedded Bookie will >> let >>>> to have only a single JVM process which runs the full stack of the >> service. >>>> >>>> For instance when I'm using Bookkeeper as a commit log I need to >> implement >>>> a commit log which uses Bookkeeper for replicated deployments, a simple >>>> "file" based commit log and a pure in-memory commit log for unit >> testing. >>>> >>>> I'm not an expert but I think it could be done using Netty >>>> LocalServerChannelFactory (and related client-side classes) and some >> tricks >>>> about the use of hostnames, registration on Zookeeper and so on >>>> >>>> Of course the same issue will be on Zookkeeper >>>> >>>> What do you think ? >>>> >>>> Maybe I can file a JIRA and try to implement a prototype >>>> >>>> Enrico Olivelli >>>> Software Development Manager @Diennea >>>> Tel.: (+39) 0546 066100 - Int. 925 >>>> Viale G.Marconi 30/14 - 48018 Faenza (RA) >>>> >>>> MagNews - E-mail Marketing Solutions >>>> http://www.magnews.it<http://www.magnews.it/> >>>> Diennea - Digital Marketing Solutions >>>> http://www.diennea.com<http://www.diennea.com/> >>>> >>>> >>>> ________________________________ >>>> >>>> Iscriviti alla nostra newsletter per rimanere aggiornato su digital ed >>>> email marketing! http://www.magnews.it/newsletter/ >>>> >>>> The information in this email is confidential and may be legally >>>> privileged. If you are not the intended recipient please notify the >> sender >>>> immediately and destroy this email. Any unauthorized, direct or >> indirect, >>>> disclosure, copying, storage, distribution or other use is strictly >>>> forbidden. >>>> >> >>
