Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide LSN in Journal for better checkpointing #279

Open
sijie opened this issue Jul 24, 2017 · 1 comment
Open

Provide LSN in Journal for better checkpointing #279

sijie opened this issue Jul 24, 2017 · 1 comment

Comments

@sijie
Copy link
Member

sijie commented Jul 24, 2017

FEATURE REQUEST

  1. Please describe the feature you are requesting.

Address the TODO item in InterleavedLedgerStorage

@Override
public void onRotateEntryLog() {
    // for interleaved ledger storage, we request a checkpoint when rotating a entry log file.
    // the checkpoint represent the point that all the entries added before this point are already
    // in ledger storage and ready to be synced to disk.
    // TODO: we could consider remove checkpointSource and checkpointSouce#newCheckpoint
    // later if we provide kind of LSN (Log/Journal Squeuence Number)
    // mechanism when adding entry.
    checkpointHolder.setNextCheckpoint(checkpointSource.newCheckpoint());
}
  1. Indicate the importance of this issue to you (blocker, must-have, should-have, nice-to-have). Are you currently using any workarounds to address this issue?

nice-to-have

  1. Provide any additional detail on your proposed use case for this feature.

N/A

@sijie sijie added this to the 4.6.0 milestone Jul 24, 2017
@sijie sijie removed this from the 4.6.0 milestone Nov 16, 2017
@ivankelly ivankelly added the triage/18-w11 Issue triage, 2018 week 11 label Mar 12, 2018
@ivankelly
Copy link
Contributor

@sijie to confirm what the comment says, it proposes that when we write to the journal for an entry, we take a mark of the point of the journal(called LSN here) at which the entry was persisted, and pass this along with the entry to the ledger storage. The ledger storage can then make it's own decision on when to sync, and when it does, it can just inform the journal of the LSN up to which all data has been persisted. This can be either push or pull from the journal PoV. Correct?

I think this is a good change, and wouldn't be particularly big. Now is a good time to do it too, or maybe once the per ledger entrylog stuff is in, which should be fairly soon.

athanatos pushed a commit to athanatos/bookkeeper that referenced this issue Jan 25, 2019
1) Handled Null case in server. Client will get InvalidACLException
2) Handled null check in create and setACL APIs in client side as mentioned in their javadoc
throws KeeperException.InvalidACLException if the ACL is invalid, null, or empty
3) Not handling any validation for async API of create and setACL in this JIRA because these API doesn't throw KeeperException explicitly. So can not throw InvalidACLExceptin from Client.  If we throw IllegalArgumentException then it will not be consistent with other sync APIs.  So Let server throw InvalidACLException for async API.

Please review and provide suggestion.

Author: bhupendra jain <bhupendra.jain@huawei.com>

Reviewers: Mohammad Arshad <arshad@apache.org>, Michael Han <hanm@apache.org>

Closes apache#279 from jainbhupendra24/ZOOKEEPER-2804-new
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants