Well Flavio, it is a extremely simple prototype where a primary broadcast
updates on a single integer to backups. So we gonna have (n-1) reads for
every write in a cluster of size n. I think sequential nodes in Zookeeper
are fine  for now, But I don't know if I am going to review that if things
begin to get more complex.

Tks a lot,
André Oriani

> Hi Andre, To guarantee that two clients that read from a ledger will
> read the same sequence of entries, we need to make sure that there is
> agreement on the end of the sequence. A client is still able to read
> from an open ledger, though. We have an open jira about informing
> clients of the progress of an open ledger (ZOOKEEPER-462), but we
> haven't reached agreement on it yet. Some folks think that it is best
> that each application use the mechanism it finds best. One option is
> to have the writer writing periodically to a ZooKeeper znode to inform
> of its progress.
>
> I would need to know more detail of your application before
> recommending you to stick with BookKeeper or switch to ZooKeeper. If
> your workload is dominated by writes, then BookKeeper might be a
> better option.
>
> -Flavio
>
> On May 19, 2010, at 1:29 AM, André Oriani wrote:
>
>> Sorry, I forgot the subject on my last message :|
>>
>> Hi all,
>> I was considering BookKeeper to implement some server replicated
>> application having one primary server as writer and many backup
>> servers
>> reading from BookKeeper concurrently. The last documentation a I had
>> access says "This writer has to execute a close ledger operation
>> before
>> any other client can read from it."  So readers cannot ready any
>> entry on
>> the ledger, even the already committed ones until writer stops
>> writing to
>> the ledger,i.e, closes it.  Is my understanding right ? Should I
>> then use
>> Zookeeper directly to achieve what I want ?
>>
>>
>> Thanks for the attention,
>> André Oriani
>>
>>
>>
>>
>>
>>
>
>


Reply via email to