Benjamin Reed commented on ZOOKEEPER-462:
if the client asks all the bookies he may not be able to get the last committed
entry if we allow for failures. the safest thing to do would be to get the last
entry from each bookie and then use the entry id in the last committed field.
that would mean that you would never be able to see the actual last committed
i think it would be good to allow the client to specify the last committed
entry on the open. that way we allow the client to figure out the last
committed record any way it wants, via communication from other processes for
example, and it would keep the open code simple: it would just use the id it
wouldn't need to worry about recovery.
> Last hint for open ledger
> Key: ZOOKEEPER-462
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-462
> Project: Zookeeper
> Issue Type: New Feature
> Components: contrib-bookkeeper
> Reporter: Flavio Paiva Junqueira
> Assignee: Flavio Paiva Junqueira
> Fix For: 3.3.0
> Attachments: ZOOKEEPER-462.patch
> In some use cases of BookKeeper, it is useful to be able to read from a
> ledger before closing the ledger. To enable such a feature, the writer has to
> be able to communicate to a reader how many entries it has been able to write
> successfully. The main idea of this jira is to continuously update a znode
> with the number of successful writes, and a reader can, for example, watch
> the node for changes.
> I was thinking of having a configuration parameter to state how often a
> writer should update the hint on ZooKeeper (e.g., every 1000 requests, every
> 10,000 requests). Clearly updating more often increases the overhead of
> writing to ZooKeeper, although the impact on the performance of writes to
> BookKeeper should be minimal given that we make an asynchronous call to
> update the hint.
This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.