We need to error and throwing an exception for the synchronous version
is what we are doing for the other calls. The asynchronous version
returns an rc in the callback.
-Flavio
On Oct 10, 2011, at 8:18 PM, Ivan Kelly wrote:
We've come across a problem with BOOKKEEPER-68[2] which I'd like to
get a wider set of opinions on.
BK-68 addresses a problem with the client that closes may possibly
overwrite each other. This breaks the correctness of BK, so must be
fixed. However, it also means the API must be changed to allow
LedgerHandle#close to error. The patch as attached to RB[1] has a
return code, though I think it should be an exception. Either way,
we make an incompatible break to the API.
I don't think it's an option to leave the close as non-erroring. We
can't leave the bug unfixed either, so I think a break is
inevitable. Doesn't anyone know of a better way to deal with a
situation like this? How has it been dealt with in the past on ZK?
Additionally, if we do go ahead with the break, I think we should
take the opportunity to make any changes to the API which we feel is
needed. This makes the disruption a one off.
Opinions?
-Ivan
[1] https://reviews.apache.org/r/2313/
[2] https://issues.apache.org/jira/browse/BOOKKEEPER-68
flavio
junqueira
research scientist
[email protected]
direct +34 93-183-8828
avinguda diagonal 177, 8th floor, barcelona, 08018, es
phone (408) 349 3300 fax (408) 349 3301
