[
https://issues.apache.org/jira/browse/BOOKKEEPER-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643983#comment-14643983
]
Ivan Kelly commented on BOOKKEEPER-860:
---------------------------------------
Ah ok. What I had in my head was different. What I thought you wanted to do was
make it so that when a resource that needs a log is created, only one ledger is
ever used, and when ownership of the resource changes, the new owner would
reopen the ledger, etc.
What is the usecase that you need these features for?
What I meant regarding the "complete break" is that, since you are starting an
API from scratch, the new API doesn't need to resemble ledger handle at all.
IMO, there are a lot of mistakes in the LedgerHandle api, but they're the kind
of thing you only see
when you've built it and used it for a while. A new api is a chance to start
fresh.
> 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)
