Added handleState enum and variable, though with only two values (OPEN, CLOSED) for now. I think there's already a preexisting possibility of data loss here or at least weird behaviour, but it should be handled in another PR.
The problem occurs if a client calls close twice concurrently with some writes outstanding. Take the local LAC in the writer to be 10, and 11-20 are outstanding writes. In this case, in the pre-immutable world, the first close will do the actual work, update the state in the metadata to closed and try to do the write to metadata with lastEntry as 10. The second local call to close sees that state is closed, so returns immediately, so the caller thinks that the ledger has been successfully closed with 10 as the last entry. However, if another client recovers the ledger, and sets the lastEntry to 20, then we have a potential for a TOAB violation. The solution would be to have 3 handle states, OPEN, CLOSING, and CLOSED, and when the state is CLOSING, only wait for the outstanding close operation to complete before returning to the client. It's out of scope for this change though. @sijie [ Full content available at: https://github.com/apache/bookkeeper/pull/1646 ] This message was relayed via gitbox.apache.org for [email protected]
