[
https://issues.apache.org/jira/browse/BOOKKEEPER-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14646899#comment-14646899
]
Sijie Guo commented on BOOKKEEPER-860:
--------------------------------------
> requiring a passwd and digest type when creating a ledger; It's not real
security, and just means you need to define a constant for passwd. There should
be sensible defaults.
+ 1 on removing passwd. it is useless.
> having more than 1 digest type
+ 1 on that
> over emphasis on striping (ensemble > write quorum). It's much better to
have write quorum equal to ensemble in most cases, and ack quorum one smaller.
that is our take in Twitter too. we only use ensemble size == write quorum
size. as it is hard to do efficient long poll when stripping.
> many different callback types. One using generics would mean less to
remember when implementing.
> using callbacks at all. ListenableFuture or rx Observables would make
more concise code at this stage.
> context objects for callbacks.
I am for ListenableFuture from guava
> exposure of netty socket channel factory in constructor.
Using builder for bookkeeper. It doesn't seem to be problem. Especially for
resource management perspective, it would good to share channel factory in a
service.
> use of Enumeration for readEntries
+1
> having reading and writing on the same handle. Users generally don't want
to be both at the same time.
there are use cases that need reading data of a writing ledger handle. but I
agree it is not clear from interface perspective.
> reads are non-streaming. You have to ask for N entries. Most people go
for 0-LAC, because it requires the least logic. Will blow up your memory if the
ledger is large.
> in general, ledger handle is far too primative to be useful. For creating
a log for a resource you need to implement a lot of complex code, especially if
you want it to be non-blocking.
I'd for keeping the ledger handle as a primitive on readings. the control on
how to streaming, reading-ahead or batching, should be done in a higher level
library/wrapper. enforcing streaming in the primitive limits the flexibility on
how people use it.
With this client API enhancement, we should also refactor the code in client
side and deprecate things that we need to deprecated.
> 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)
