-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7749/#review12866
-----------------------------------------------------------
Thanks Ivan for the patch. There is few compilation errors
'lh.getLedgerMetadata().getQuorumSize()'. could you please rebase it in latest
trunk.
Just few thoughts:
comment#1:
getSentHosts() method not required to be synchronized, its already being called
from a sync method maybeSendSpeculativeRead()
comment#2:
}, 2000, 2000); Can we make this timer interval configurable and defaulting to
2000.
comment#3:
How about scheduling the speculativeReadTimer after sending all the request, so
will be able to avoid boolean flag 'requestsSent' usage?
comment#4:
Please make the ReadContext class to 'private static class ReadContext'
comment#5:
+ BitSet b = new BitSet(ensemble.size());
+
+ for (int i = 0; i < b.length(); i++) {
+ if (b.get(i)) {
+ b.set(lh.distributionSchedule.getBookieIndex(entryId, i));
+ }
+ }
Here by default all the bitset values will be init to false, so here
b.set(lh.distributionSchedule.getBookieIndex(entryId, i)); will be unreachable.
isn't it?
comment#6
Could you please add the "heardFromHosts.add(rctx.to);" after checking
'entry.complete(rctx.to, buffer)'.
Consider the case where read entry throws BKDigestMatchException and the entry
still needs retryals. But the timer sees a heardFromHosts value and it will
stop sending next read.
- Rakesh R
On Oct. 26, 2012, 5:54 p.m., Ivan Kelly wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/7749/
> -----------------------------------------------------------
>
> (Updated Oct. 26, 2012, 5:54 p.m.)
>
>
> Review request for bookkeeper.
>
>
> Description
> -------
>
> Scenario:
>
> 1) Start three bookies. Create ledger with ensemblesize=3, quorumsize=2
> 2) Add 100 entries to this ledger
> 3) Make first bookie down and read the entries from 0-99
>
> Output: Each entry is going to fetch from the failed bookie and is waiting
> for the bookie connection timeout, only after failure going to next bookie.
> This is affecting the read entry performance.
>
> Impact: Namenode switching time will be affected by adding this failed bookie
> readTimeOut also.
>
>
> This addresses bug BOOKKEEPER-336.
> https://issues.apache.org/jira/browse/BOOKKEEPER-336
>
>
> Diffs
> -----
>
>
> bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java
> aeb6886
>
> Diff: https://reviews.apache.org/r/7749/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Ivan Kelly
>
>
