Flavio Junqueira updated ZOOKEEPER-831:

    Attachment: ZOOKEEPER-831.patch

I have implemented the modification Ivan suggested to avoid a new call in the 
API of LedgerHandler.

The comment on the acquire call, however, is a little trickier. First, we can't 
acquire a permit in pendingAddOp.initiate() because the call to asyncAddEntry 
and the call to initiate are decoupled (a separate thread executes initiate). 
To have the acquire call being effective in throttling the client application, 
we need to put it either before or after submitOrdered in asyncAddEntry. Given 
that there is only one checked exception, which is thrown by the acquire call 
itself, it is my impression that it is ok to place the call before, and placing 
it before is the same order the we followed for read operations in 

What do you think, Ivan?

> BookKeeper: Throttling improved for reads
> -----------------------------------------
>                 Key: ZOOKEEPER-831
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-831
>             Project: Zookeeper
>          Issue Type: Bug
>          Components: contrib-bookkeeper
>    Affects Versions: 3.3.1
>            Reporter: Flavio Junqueira
>            Assignee: Flavio Junqueira
>             Fix For: 3.4.0
>         Attachments: ZOOKEEPER-831.patch, ZOOKEEPER-831.patch, 
> ZOOKEEPER-831.patch
> Reads and writes in BookKeeper are asymmetric: a write request writes one 
> entry, whereas a read request may read multiple requests. The current 
> implementation of throttling only counts the number of read requests instead 
> of counting the number of entries being read. Consequently, a few read 
> requests reading a large number of entries each will spawn a large number of 
> read-entry requests. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to