[
https://issues.apache.org/jira/browse/BOOKKEEPER-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14645536#comment-14645536
]
Sijie Guo commented on BOOKKEEPER-860:
--------------------------------------
[~jujjuri][~ikelly]
I think the requirements here mostly focus on giving flexibility to clients on
controlling entry id and ledger id. It doesn't change the semantic and ordering
guarantee that current bookkeeper provides. so I would suggest doing as below:
*API*
- providing a new interface about 'ledger handle' on allowing accepting entry
id. (I don't have a good name for it right now. I will use WriteLedgerHandle
for right now)
{code}
public interface WriteLedgerHandle {
// we could use guava's listenable future for new api, or just using
existing AddCallback is okay too.
ListenableFuture<Void> addEntry(long entryId, ByteBuffer data);
}
{code}
- add a new method in BookKeeper to allow creating a ledger with passing in
ledger id.
{code}
ListenableFuture<WriteLedgerHandle> createWriteLedgerHandle(int ensSize, int
writeQuorumSize, ...);
{code}
*Semantic*
for the entry id, you should reuse current lac and ordering guarantee logic. it
is easily to prevent duplication by checking lac and pending entries in the
client, which it could reject any add with duplicated entry id. it is hard to
enforce starting from zero and no holes in the implementation, application
takes the responsibility of the enforcement.
for the ledger id, BOOKKEEPER-438 is already working on moving ledger id
generation out of LedgerManager interface. it would be easily to allow passing
in ledger id after that. Since the ledger manager implementation is already
prevent creating ledger with duplicated ledger id, so it should be good from
semantic perspective.
*Tasks*
in order to achieve that, the jira could be break down as following sub-tasks:
- BOOKKEEPER-438 (for moving ledger id generation out of ledger manager)
- Support creating a ledger with pass-in ledger id (it might change the
LedgerCreateOp to take ledger id. and move the ledger id generation out of
LedgerCreateOp to BookKeeper on #createLedger)
- Add the new class of WriteLedgerHandle to allow accepting pass-in entry id.
(This might require bunch of code cleanup in LedgerHandle, such moving pending
entries management, lac management to a separated class that could be re-used
by LedgerHandle and WriteLedgerHandle)
> Enhance client API
> ------------------
>
> Key: BOOKKEEPER-860
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-860
> Project: Bookkeeper
> Issue Type: Improvement
> Components: bookkeeper-client
> Affects Versions: 4.3.1
> Reporter: Venkateswararao Jujjuri
> Assignee: Venkateswararao Jujjuri
> Labels: newbie
> Fix For: 4.4.0
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Today's BK client API generates entryId and LedgerHandle for the caller.
> While this is very convenient and makes the life of caller very simple and
> easy,
> this model may not be very suitable where application would like to have
> better control.
> In order to facilitate applications/users of BK aspiring to have more control
> following enhancements are proposed for BK client API:
>
> - API enhancement to accept entryID:
> Enhance BK client API to pass entryId as an input and the caller must
> guarantee the following:
> * entryIds are never duplicated
> * entryIds are sequential starting from 0.
> * entryIds have no holes.
> - API enhancement to accept LedgerHandle
> Applications are allowed to pass-in ledgerId provided:
> * ledgerId is unique within the cluster.
> * Or even better, if using GUID (128 bit) virtually guarantees universal
> uniqueness.
> * Need to bypass current ledgerId generation logic.
> - Allow multiple entities (threads/processes) write to the ledger as long as
> there is only one writer at the given instance of time.
> - Currently ledgerHandle interface accepts byteArray as input, but sockets
> use byteBuffer. We will add additional functions to the new classes to
> accept both byteBuffers and byteArrays.
> - Sijie suggested to create a new classes that extents existing classes to
> accept LedgerId and entryId as inputs.This avoids any confusion with existing
> interfaces, and makes it explicit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
