[
https://issues.apache.org/jira/browse/BOOKKEEPER-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643034#comment-14643034
]
Venkateswararao Jujjuri commented on BOOKKEEPER-860:
----------------------------------------------------
How do I assign it to myself?
> 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
> 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)
