[DISCUSS] Incompatible API changes

[Ivan Kelly <iv...@yahoo-inc.com>]

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

Re: [DISCUSS] Incompatible API changes

[Flavio Junqueira <fp...@yahoo-inc.com>]

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

fpj@yahoo-inc.com
direct +34 93-183-8828

avinguda diagonal 177, 8th floor, barcelona, 08018, es
phone (408) 349 3300    fax (408) 349 3301