In my understanding, the semantics we provide is closer to your option b), but
not quite the way you put it. The contract is that upon an acknowledgement to a
request to add an entry, we guarantee that we have at least ackQuorumSize
copies stored in bookies. We send copies to more bookies (writeQuorumSize) to
avoid slow bookies as you say.
It is correct that if there aren't enough bookies we will throw an exception,
and you imply that it is perhaps unnecessary, since the contract is not to
store on writeQuorumSize bookies anyway. On the other hand, this is what the
application asked us to do, so bk should fulfill its commitment. In the case
there aren't enough bookies and the application gets an exception, it closes
the ledger and create a new one with fewer bookies.
-Flavio
On Dec 12, 2012, at 6:47 AM, Sijie Guo wrote:
> Hello guys,
>
> AckSet is introduced recently to resolve slow bookie issue. But the semantic
> of 'writeQuorumSize' is not so clearly. What kind of goal we should achieve
> for 'writeQuorumSize':
>
> a) an entry is written to all 'writeQuorumSize' bookies eventually
> b) just guarantee issuing 'writeQuorumSize' bookies and at least
> 'ackQuorumSize' bookies acked. other bookies we don't care about it.
>
> semantic a):
>
> if we want a), currently it doesn't work. for example, writing ensemble (A,
> B, C, D), writeQuorumSize is 3, ackQuorumSize is 2 and C is a slow bookie.
>
> 1. client adding entries 0. and entry 0 is acked.
> 2. at time T, C is timeout (due to it is slow of failed). so the adding entry
> 0 at C would failed with BookieHandleNotAvailable. It would try to pickup a
> new bookie and unsetSuccessAndSentWriteRequest to new bookie. But nothing
> would be executed since pendingAddOps queue is empty. so nothing would be
> added in the new bookie.
>
> private void unsetSuccessAndSendWriteRequest(final int bookieIndex) {
> for (PendingAddOp pendingAddOp : pendingAddOps) {
> pendingAddOp.unsetSuccessAndSendWriteRequest(bookieIndex);
> }
> }
>
> If we want to achieve semantic a), it would be difficult to handle client
> failure case.
>
> semantic b):
>
> if we just want achieve b), so do we need to pickup a new bookie replace the
> slow bookie? Also even a new bookie is replaced, no entry would be added
> again to it, since pendingAddOps is empty.
>
> I raised this question, is because if we pickup a new bookie replace the slow
> bookie, it might cause closing ledger due to NotEnoughBookiesException. It is
> easy to produce the case using existing test case. Please see the attached
> file.
>
> if we allow b), so maybe we don't need handleBookieFailure when a late
> response arrived at the client after its entry has been acked.
>
> -Sijie
