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

Exposing the broker entry metadata to client #11553

Merged
merged 10 commits into from
Aug 23, 2021

Conversation

LeBW
Copy link
Contributor

@LeBW LeBW commented Aug 4, 2021

Motivation

This is an improvement to PIP-70. Now the client is able to get the broker entry metadata.

Modifications

  1. increment the client protocol version from 17 to 18.
  2. add a configuration enableExposingBrokerEntryMetadataToClient in the broker configuration.
  3. Let the broker send the broker entry metadata to the client when client protocol version >= 18 and enableExposingBrokerEntryMetadataToClient is true.
  4. Add client support for broker entry metadata. Add two methods getBrokerPublishTime() and getIndex() to utilize the broker entry metadata in Message.

Verifying this change

  • Make sure that the change passes the CI checks.

Added test for getBrokerPublishTime() and getIndex().

Does this pull request potentially affect one of the following parts:

If yes was chosen, please highlight the changes

  • Dependencies (does it add or upgrade a dependency): (no)
  • The public API: (yes)
  • The schema: (no)
  • The default values of configurations: (no)
  • The wire protocol: (yes)
  • The rest endpoints: (no)
  • The admin cli options: (no)
  • Anything that affects deployment: (no)

Documentation

For contributor

For this PR, do we need to update docs?

  • If yes, please update docs or create a follow-up issue if you need help.

@codelipenghui codelipenghui requested a review from hangc0276 August 4, 2021 12:13
@codelipenghui codelipenghui added this to the 2.9.0 milestone Aug 4, 2021
@codelipenghui codelipenghui removed the request for review from hangc0276 August 4, 2021 12:14
@Anonymitaet
Copy link
Member

Thanks for your contribution. For this PR, do we need to update docs?

(The PR template contains info about doc, which helps others know more about the changes. Can you provide doc-related info in this and future PR descriptions? Thanks)

@LeBW
Copy link
Contributor Author

LeBW commented Aug 5, 2021

Thanks for your contribution. For this PR, do we need to update docs?

(The PR template contains info about doc, which helps others know more about the changes. Can you provide doc-related info in this and future PR descriptions? Thanks)

Thanks. "Broker Entry Metadata" is a new feature since 2.8.0, but I haven't found any doc about it for now. Maybe it's better to add some docs for it? (Not just for my PR)

@Anonymitaet
Copy link
Member

@LeBW thanks for your suggestion. Would you like to add some docs from your perspective?

@LeBW
Copy link
Contributor Author

LeBW commented Aug 5, 2021

@LeBW thanks for your suggestion. Would you like to add some docs from your perspective?

Yeah, I can do it later.

@Anonymitaet Anonymitaet added the doc-required Your PR changes impact docs and you will update later. label Aug 5, 2021
@Anonymitaet
Copy link
Member

Anonymitaet commented Aug 5, 2021

@LeBW you can ping me to review the doc and look forward to your contribution, thanks

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 few comments

This is an API change and wire protocol change, can you please advertise it on the dev@ mailing list?

@LeBW
Copy link
Contributor Author

LeBW commented Aug 6, 2021

Great work. I left a few comments

This is an API change and wire protocol change, can you please advertise it on the dev@ mailing list?

Thanks for your suggestion. I'll write an email to advertise it.

…rom long to Optional<Long>. 2. Improve the unit test.
@LeBW LeBW requested a review from eolivelli August 9, 2021 12:50
@LeBW LeBW force-pushed the client-brokerentrymetadata branch from 0666188 to 93f066c Compare August 9, 2021 13:00
@@ -186,6 +186,7 @@
private boolean preciseTopicPublishRateLimitingEnable;
private boolean encryptionRequireOnProducer;

private boolean exposingBrokerEntryMetadataToClientEnabled;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need to add ServerCnx? Is it able to get from the ServiceConfiguration directly?


@Override
public Optional<Long> getIndex() {
if (brokerEntryMetadata != null && brokerEntryMetadata.hasIndex()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

For a batch message, we only have one index in the broker entry metadata, we will get the same index for the individual messages of a batch.

Copy link
Contributor

@aloyszhang aloyszhang Aug 10, 2021

Choose a reason for hiding this comment

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

Agree with @codelipenghui , for a batch message, we need to caculate the individual index for each message from the Entry index and batch size

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you all. Let me fix it.

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

@LeBW LeBW force-pushed the client-brokerentrymetadata branch from e5f6a0b to 1025378 Compare August 12, 2021 01:35
@Cleanup
Producer<byte[]> producer = pulsarClient.newProducer()
.topic(topic)
.enableBatching(true)
Copy link
Contributor

Choose a reason for hiding this comment

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

The default batching delay is 1ms, it's better to increase the batching delay to such as 1min and force flush the producer, because if we are running the test on a machine which with leak resource, we might get only 1 message in a batch.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can send 5 messages and flush them and send 5 messages again, to flush again, make sure we got 2 batch message and 10 individual messages.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Got it. Fixed.

if (brokerEntryMetadata != null && brokerEntryMetadata.hasIndex()) {
if (msgMetadata.hasNumMessagesInBatch() && messageId instanceof BatchMessageIdImpl) {
int batchIndex = ((BatchMessageIdImpl) messageId).getBatchIndex();
return Optional.of(brokerEntryMetadata.getIndex() - batchIndex);
Copy link
Contributor

Choose a reason for hiding this comment

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

If the index is 10 and the batch size is 5, we will get 10, 9, 8, 7, 6 for these 5 messages?

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

Copy link
Contributor

@codelipenghui codelipenghui left a comment

Choose a reason for hiding this comment

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

Great contribution!

@codelipenghui
Copy link
Contributor

@eolivelli Please help review the PR again.

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 !

LGTM

// skip broker entry metadata if consumer-client doesn't support broker entry metadata or the
// features is not enabled
if (cnx.getRemoteEndpointProtocolVersion() < ProtocolVersion.v18.getValue()
|| !cnx.isExposingBrokerEntryMetadataToClientEnabled()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

We can get the configuration through the following dependency paths
PulsarCommandSenderImpl -> ServerCnx -> BrokerService -> PulsarService -> configuration
isExposingBrokerEntryMetadataToClientEnabled in ServerCnx can be removed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for your suggestion. I've removed it in ServerCnx

@LeBW LeBW requested a review from 315157973 August 14, 2021 02:54
Commands.skipBrokerEntryMetadataIfExist(metadataAndPayload);
// skip broker entry metadata if consumer-client doesn't support broker entry metadata or the
// features is not enabled
if (cnx.getRemoteEndpointProtocolVersion() < ProtocolVersion.v18.getValue()
Copy link
Contributor

Choose a reason for hiding this comment

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

It is better to use the FeatureFlag mechanism instead of checking the ProtocolVersion. This will ensure clients can phase in with the support of this feature.

Copy link
Contributor

Choose a reason for hiding this comment

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

that's interesting. I wasn't aware of that mechanism

Copy link
Contributor

Choose a reason for hiding this comment

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

Make sense, even if the client with ProtocolVersion.v18 but does not support get broker entry metadata, the broker can skip the broker entry metadata to reduce the network workload.

Copy link
Contributor Author

@LeBW LeBW Aug 18, 2021

Choose a reason for hiding this comment

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

It is better to use the FeatureFlag mechanism instead of checking the ProtocolVersion. This will ensure clients can phase in with the support of this feature.

Thanks for your suggestion. Maybe it's better to check both the FeatureFlag and the ProtocolVersion ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is better to use the FeatureFlag mechanism instead of checking the ProtocolVersion. This will ensure clients can phase in with the support of this feature.

PIP-70 adds a feature flag supports_broker_entry_metadata, so I use it to check here. Can you review it again?

@Anonymitaet
Copy link
Member

@LeBW thanks for your contribution! Please do not forget to add docs accordingly to allow users to know your great code changes.

@LeBW LeBW requested a review from merlimat August 19, 2021 01:06
@codelipenghui codelipenghui merged commit a7a3721 into apache:master Aug 23, 2021
@Anonymitaet Anonymitaet removed the doc-required Your PR changes impact docs and you will update later. label Oct 25, 2021
eolivelli added a commit to datastax/starlight-for-kafka that referenced this pull request Feb 9, 2022
bharanic-dev pushed a commit to bharanic-dev/pulsar that referenced this pull request Mar 18, 2022
### Motivation
This is an improvement to [PIP-70](https://github.com/apache/pulsar/wiki/PIP-70%3A-Introduce-lightweight-broker-entry-metadata). Now the client is able to get the broker entry metadata.

### Modifications
1. increment the client protocol version from 17 to 18.
2. add a configuration `enableExposingBrokerEntryMetadataToClient` in the broker configuration.
3. Let the broker send the broker entry metadata to the client when `client protocol version >= 18` and `enableExposingBrokerEntryMetadataToClient` is true.
4. Add client support for broker entry metadata. Add two methods `getBrokerPublishTime()` and `getIndex()` to utilize the broker entry metadata in `Message`.
dlg99 pushed a commit to dlg99/pulsar that referenced this pull request Jun 15, 2022
This is an improvement to [PIP-70](https://github.com/apache/pulsar/wiki/PIP-70%3A-Introduce-lightweight-broker-entry-metadata). Now the client is able to get the broker entry metadata.

1. increment the client protocol version from 17 to 18.
2. add a configuration `enableExposingBrokerEntryMetadataToClient` in the broker configuration.
3. Let the broker send the broker entry metadata to the client when `client protocol version >= 18` and `enableExposingBrokerEntryMetadataToClient` is true.
4. Add client support for broker entry metadata. Add two methods `getBrokerPublishTime()` and `getIndex()` to utilize the broker entry metadata in `Message`.

(cherry picked from commit a7a3721)
eolivelli pushed a commit to datastax/pulsar that referenced this pull request Jun 16, 2022
This is an improvement to [PIP-70](https://github.com/apache/pulsar/wiki/PIP-70%3A-Introduce-lightweight-broker-entry-metadata). Now the client is able to get the broker entry metadata.

1. increment the client protocol version from 17 to 18.
2. add a configuration `enableExposingBrokerEntryMetadataToClient` in the broker configuration.
3. Let the broker send the broker entry metadata to the client when `client protocol version >= 18` and `enableExposingBrokerEntryMetadataToClient` is true.
4. Add client support for broker entry metadata. Add two methods `getBrokerPublishTime()` and `getIndex()` to utilize the broker entry metadata in `Message`.

(cherry picked from commit a7a3721)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants