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
