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-68: WaitForExclusive producer access mode #8992

Merged
merged 4 commits into from
Dec 18, 2020

Conversation

merlimat
Copy link
Contributor

Motivation

Implemented the 2nd part of the proposal for PIP-68.

With WaitForExclusive mode, a producer is pending until there are other producers connected and then it will be created.

The change in the client logic is to make sure that we don't time out the producer creation request. The broker will send a 1st response saying that the producer creation is pending. At this point the client will disable the timeout on the original request.

@merlimat merlimat added the type/feature The PR added a new feature or issue requested a new feature label Dec 17, 2020
@merlimat merlimat added this to the 2.8.0 milestone Dec 17, 2020
@merlimat merlimat self-assigned this Dec 17, 2020
@sijie sijie added area/broker doc-required Your PR changes impact docs and you will update later. labels Dec 18, 2020
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.

Great work.
I left a question and a super minor comment t for a typo

// If the producer is queued waiting, we will get an immediate notification
// that we need to pass to client
if (isActive()) {
log.info("[{}] Producer is waiting in qeuue: {}", remoteAddress, producer);
Copy link
Contributor

Choose a reason for hiding this comment

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

Typo qeuue

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

if (requestFuture != null) {
log.info("{} Producer {} has been queued up at broker. request: {}", ctx.channel(),
success.getProducerName(), requestId);
requestFuture.markAsResponded();
Copy link
Contributor

Choose a reason for hiding this comment

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

What happens if the PulsarClient gets closed or there is a network error?
Are we guaranteed to fail and do not wait forever?

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, the marking of the future is only for timeout within a single connection. When a connection fails, everything that was in that connections is marked as failed and will trigger a retry.

Copy link
Contributor

Choose a reason for hiding this comment

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

Good

@merlimat merlimat merged commit 99476d3 into apache:master Dec 18, 2020
@merlimat merlimat deleted the wait-for-exclusive-producer branch December 18, 2020 22:20
@Anonymitaet
Copy link
Member

Anonymitaet commented Mar 11, 2021

@merlimat thanks for your great work. Would you like to add docs accordingly? Then I can help review, thanks

@Anonymitaet
Copy link
Member

Anonymitaet commented Mar 15, 2021

@merlimat we are adding docs, should we create a new section named "Access mode" under the Producer chapter and add the Shared, Exclusive, and WaitForExclusive modes there?

I've drafted a doc, could you please help review? Thanks for your answer.

@Anonymitaet
Copy link
Member

@merlimat could you please take a look at the draft? Thanks.

@Anonymitaet Anonymitaet removed the doc-required Your PR changes impact docs and you will update later. label Mar 18, 2021
checkArgument(producer.getTopic() == this);

CompletableFuture<Optional<Long>> future = new CompletableFuture<>();

incrementTopicEpochIfNeeded(producer)
.thenAccept(epoch -> {
lock.readLock().lock();
Copy link
Contributor

Choose a reason for hiding this comment

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

Hi @merlimat @sijie , this place makes me a little puzzled and I would like to ask why we need to change readlock to writelock?

Choose a reason for hiding this comment

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/broker 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.

None yet

6 participants