You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/06/02 20:40:04 UTC

[jira] [Commented] (BOOKKEEPER-1093) Piggyback LAC on ReadResponse

    [ https://issues.apache.org/jira/browse/BOOKKEEPER-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035383#comment-16035383 ] 

ASF GitHub Bot commented on BOOKKEEPER-1093:
--------------------------------------------

GitHub user sijie opened a pull request:

    https://github.com/apache/bookkeeper/pull/180

    BOOKKEEPER-1093: Piggyback LAC on ReadResponse

    This change is based #178 - (you can review git sha 40ca8c2)
    
    bookkeeper: LAC piggyback at read response
    
            - bookie server changes
              * cache maximum lac in file info
              * provide getLastAddConfirmed & setLastAddConfirmed in ledger storage
              * addEntry will set its lac thru setLastAddConfirmed
              * readEntry will read latest lac and piggyback
            - client change
              * check whether the response has lac piggybacked, if there is lac update lac in its corresponding ledger handle.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/sijie/bookkeeper piggyback_lac

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/bookkeeper/pull/180.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #180
    
----
commit 3db0b84570dec166855c70105a5cbf6f2ec14ea2
Author: Sijie Guo <si...@twitter.com>
Date:   2014-01-21T00:42:28Z

    bookkeeper recovery improvement (part-1): refactor PendingReadOp
    
    this change is the first part of improving bookkeeper recovery. it is basically a refactor change, which:
    
    - abstract an interface for LedgerEntryRequest in PendingReadOp
    - rename current implementation to SequenceReadRequest, which read the entry in the sequence of quorum.
    
    RB_ID=266137

commit 80ffc6ca86b5e8a63dc3b9baf846ad139d7beea1
Author: Sijie Guo <si...@apache.org>
Date:   2017-06-01T19:11:40Z

    Address conflicts

commit f0fb89cbdfed6c6b0d519a25ea2ea67dcd72834e
Author: Sijie Guo <si...@twitter.com>
Date:   2014-01-21T00:49:52Z

    bookkeeper recovery improvement (part-2): add a parallel reading request in PendingReadOp
    
    - add a parallel reading request in PendingReadOp
    - allow PendingReadOp to configure whether to do parallel reading or not
    - add flag in ClientConfiguration to allow configuring whether to do parallel reading in LedgerRecoveryOp or not.
    
    RB_ID=266139

commit db3e98ba9250b622db80cac8dd6dbd2761a32381
Author: Sijie Guo <si...@apache.org>
Date:   2017-06-01T20:00:01Z

    Address conflicts

commit 8b8a3c8db86a11a30efb14d04b33bfcd461a6f05
Author: Sijie Guo <si...@twitter.com>
Date:   2014-01-21T00:55:30Z

    bookkeeper recovery improvement (part-3): add a ReadEntryListener to callback on individual request.
    
    - add read entry listener which allow doing batch read, but callback on individual entries in sequence. so in recovery op, we could issue batch reads, then on each individual callback do add entry and stop when received NoSuchEntry.
    
    RB_ID=266143

commit 455afdad38103db978638a9e3f8774623efbb82a
Author: Sijie Guo <si...@twitter.com>
Date:   2014-01-21T01:00:30Z

    bookkeeper recovery improvement (part-4): allow batch reading in ledger recovery
    
    - enable batch read in ledger recovery, so we could parallel reading to improve recovery time.
    
    RB_ID=266145

commit d9b9d98518d8ee0b1951ad2eee8ce28820a4c652
Author: Sijie Guo <si...@apache.org>
Date:   2017-06-01T22:04:44Z

    Address conflicts in merge

commit 40ca8c2116ae072d459af5d0eca47d6d6a3846ec
Author: Sijie Guo <si...@apache.org>
Date:   2017-06-02T20:36:03Z

        bookkeeper: LAC piggyback at read response
    
        - bookie server changes
          * cache maximum lac in file info
          * provide getLastAddConfirmed & setLastAddConfirmed in ledger storage
          * addEntry will set its lac thru setLastAddConfirmed
          * readEntry will read latest lac and piggyback
        - client change
          * check whether the response has lac piggybacked, if there is lac update lac in its corresponding ledger handle.

----


> Piggyback LAC on ReadResponse
> -----------------------------
>
>                 Key: BOOKKEEPER-1093
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-1093
>             Project: Bookkeeper
>          Issue Type: Sub-task
>          Components: bookkeeper-client, bookkeeper-server
>            Reporter: Sijie Guo
>            Assignee: Sijie Guo
>             Fix For: 4.5.0
>
>
> Currently LAC is only updated when the reader explicitly calls #readLastAddConfirmed(). In tailing-read use cases, it will not wise to keep calling #readLastAddConfirmed, especially when the traffic is huge.
> The idea here is piggy-back LAC along with the read responses. so the client will get advanced LAC along with read responses. so it will reduce calling #readLastAddConfirmed. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)