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

PIP-135: Added Etcd MetadataStore implementation #13225

Merged
merged 16 commits into from
Jan 21, 2022
Merged

Conversation

merlimat
Copy link
Contributor

Motivation

Added a new MetadataStore implementation based on Etcd client.

The new implementation has all the feature as the ZK based backend:

  • Batching of read/write requests
  • Session watcher
  • Lease manager

@merlimat merlimat added the type/feature The PR added a new feature or issue requested a new feature label Dec 10, 2021
@merlimat merlimat added this to the 2.10.0 milestone Dec 10, 2021
@merlimat merlimat self-assigned this Dec 10, 2021
@merlimat merlimat added doc-required Your PR changes impact docs and you will update later. and removed doc-label-missing labels Dec 10, 2021
@apache apache deleted a comment from github-actions bot Dec 10, 2021
@Slf4j
public class EtcdMetadataStore extends AbstractBatchedMetadataStore {

static final String ETCD_SCHEME_IDENTIFIER = "etcd:";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be "etcd://" to be consistent with other implementations ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was considering that, though it kind of gets weird with url like etcd://http://my-service:2379. The current form of etcd:http://my-service:2379 seems a bit easier to see.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we need to update the memory:// to "memory:" and "rocksdb://" to "rocksdb:"? It's better to make them consistent.

});

if (retryOnFailure) {
future.exceptionally(ex -> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we return the future that only completes when retried success ?

// Re-create the lease before notifying that we are reconnected
createLease(true)
.thenRun(() -> {
super.receivedSessionEvent(event);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If createLease failed the first time, the receivedSessionEvent will not be called.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that is intended.

The code here can certainly be refactored to make it easier. The intention here is:

  • At startup, we create the lease. If we fail, we bubble up the exception (eg: broker fails to start)
  • If we lose the lease while running, depending on the configuration we either kill the broker or try to reconnect.
  • When we don't kill the broker, we re-establish a new lease and we keep trying doing that indefinitely

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • When we don't kill the broker, we re-establish a new lease and we keep trying doing that indefinitely

My point is, in this case, if we finally re-establish the new lease (after some retries), is it ok that we don't call super.receivedSessionEvent(event)? Current CompletableFuture returned by createLease only tracks the first try.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After reconnection, the receivedSessionEvent() will be called through the session watcher class.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, thx~

@eolivelli
Copy link
Contributor

do we need a PIP here ? it is a big feature

@merlimat
Copy link
Contributor Author

do we need a PIP here ? it is a big feature

If you discount the license files, it's 1 single file containing an implementation which is not enabled by default and which does not affect anything else.

I can create one.. but I don't see many design choices here to describe.

Copy link
Contributor

@eolivelli eolivelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that this will be a new feature that should be advertised and discussed on dev@
This is why I am thinking about starting a PIP.

I am pretty sure that no one will object to committing this patch, but for the benefit of the many folks in the community that are not following the github pull requests flow it is better to advertise about this work.

I will do my review when I wil be back form vacation (no need to wait for me, for sure)

@merlimat merlimat changed the title Added Etcd MetadataStore implementation PIP-135: Added Etcd MetadataStore implementation Jan 12, 2022
@Slf4j
public class EtcdMetadataStore extends AbstractBatchedMetadataStore {

static final String ETCD_SCHEME_IDENTIFIER = "etcd:";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we need to update the memory:// to "memory:" and "rocksdb://" to "rocksdb:"? It's better to make them consistent.

}
}

private synchronized CompletableFuture<Void> createLease(boolean retryOnFailure) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does retryOnFailure is to retry in the background but the caller will get an exception?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this is after we created the lease the first time, so that we can re-create it in background. If we fail, we notify the session listener to change the current state and we keep retrying in background.

@merlimat
Copy link
Contributor Author

Shall we need to update the memory:// to "memory:" and "rocksdb://" to "rocksdb:"? It's better to make them consistent.

Good point, we should do that in a different PR.

@Override
protected CompletableFuture<Boolean> existsFromStore(String path) {
return kv.get(ByteSequence.from(path, StandardCharsets.UTF_8), EXISTS_GET_OPTION)
.thenApply(gr -> gr.getCount() == 1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to ensure the async callback is executed in metadata-store thread.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Fixed it.

@merlimat merlimat merged commit 1ad6e5b into apache:master Jan 21, 2022
@merlimat merlimat deleted the etcd branch January 21, 2022 22:01
@Anonymitaet Anonymitaet added doc-complete Your PR changes impact docs and the related docs have been already added. and removed doc-required Your PR changes impact docs and you will update later. labels Jan 24, 2022
codelipenghui added a commit that referenced this pull request Jan 27, 2022
Using the consistent metadata store scheme name.

- RocksDB -> rocksdb:
- ZooKeeper -> zk:
- Memory -> memory:
- Ectd -> etcd:

Context: #13225 (comment)
Nicklee007 pushed a commit to Nicklee007/pulsar that referenced this pull request Apr 20, 2022
Using the consistent metadata store scheme name.

- RocksDB -> rocksdb:
- ZooKeeper -> zk:
- Memory -> memory:
- Ectd -> etcd:

Context: apache#13225 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc-complete Your PR changes impact docs and the related docs have been already added. type/feature The PR added a new feature or issue requested a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants