[ https://issues.apache.org/jira/browse/BOOKKEEPER-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490536#comment-13490536 ]
Sijie Guo commented on BOOKKEEPER-455: -------------------------------------- {quote} Suppose bookie persist entry 1, 3, 4, and entry 2 failed and being retried (TCP handles IP layer package lost), and now bookie crash. If the ledger is recovered, last-confirmed-entry-id can be set to 4. When readers try to read 2, it will not get it. {quote} some explanations about LAC. during initialization, -1 is LAC. case1: 1) adding 0 : sending 0 with (LAC=-1) 2) acked 0 : LAC changed from -1 to 0 3) adding 1 : sending 1 with (LAC=0) 4) acked 1 : LAC changed from 0 to 1 case2: 1) adding 0, 1, 2, 3, 4 : sending 0, 1, 2, 3, 4 with (LAC=-1) 2) acked 0: LAC changed from -1 to 0 3) acked 1: LAC changed from 0 to 1 4) failed to add 2. in this case, LAC is -1 since the hint stored with 0~4 are -1. and LAC would not be larger than the entry that isn't ACKed. > Bookie recovery made assumption that entries are persisted in entry id order > ---------------------------------------------------------------------------- > > Key: BOOKKEEPER-455 > URL: https://issues.apache.org/jira/browse/BOOKKEEPER-455 > Project: Bookkeeper > Issue Type: Bug > Components: bookkeeper-server > Affects Versions: 4.2.0 > Reporter: Yixue (Andrew) Zhu > Priority: Minor > > The entries sent by bookkeeper client can be out of order (due to network). > The client uses queue to track last-confirmed-entry-id correctly. > The bookie server will happily persist the entries out of order, i.e. gaps > are possible. If bookie crash, the recovery can cause last-confirmed-entry-id > to be set to the last-entry persisted by bookie. The gap is not tracked nor > detected at server side. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira