[GitHub] athanatos commented on issue #1077: [RFC] ISSUE #1067: PendingReadOp: recovery, return NoSuchEntry on wQ-aQ+1 e?

[GitBox <gi...@apache.org>]

athanatos commented on issue #1077: [RFC] ISSUE #1067: PendingReadOp: recovery, return NoSuchEntry on wQ-aQ+1 e?
URL: https://github.com/apache/bookkeeper/pull/1077#issuecomment-361443121
 
 
   The main issue here is that we'd like to be able to return NoSuchEntry on entry e for a recovery read as soon as we can rule out a successful write for entry e.  To that end, it seems sufficient to wait until we have more than wQ-aQ NoSuchEntry/Ledger responses.
   
   There is existing code (for both seq and parallel) that returns NoSuchEntry if
   1) we've tried to send to all bookies
   2) all bookies have either responded or netty has reported that it cannot send the read (BKException.Code.BookieHandleNotAvailableException)
   3) at least wQ-aQ+1 bookies have responded with NoSuchEntry/Ledger
   4) no errors other than NoSuchEntry/Ledger or BookieHandleNotAvailableException have been seen
   
   @ivankelly That logic seems to have been introduced in b6c1a8bbd7c2d44c2edb59d9938fa073f6f478de .  Is that logic only intended to apply to the recovery read case, or is it important more generally?  If the former, I think I should be able to simply replace it, right?

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services