-
Notifications
You must be signed in to change notification settings - Fork 0
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
[feat][client] PIP-224 Part 2: Add TopicMessageIdSerDes #20
base: master
Are you sure you want to change the base?
Conversation
Master Issue: apache#18616 ### Motivation Introduce `TopicMessageId` to support getting the owner topic of a `MessageId`. When a `MessageId` is retrieved from a received message, the owner topic will be correctly set by the client library. When it's returned by `Producer#send`, this PR provides a `TopicMessageId#create` method to configure the owner topic. `acknowledge` APIs are affected only for the error cases: when a `MessageId` other than a `TopicMessageId` is accepted on a multi-topics consumer, `PulsarClientException.NotAllowedException` will be thrown. The semantic of the `seek(MessageId)` API is changed. Now if a `TopicMessageId` is accepted on a multi-topics consumer, the seek behavior will happen on the internal consumer of the owner topic. ### Modifications - Add the `TopicMessageId` interface. - In `MultiTopicsConsumerImpl#doAcknowledge`, complete the future with `NotAllowedException` if the argument is not a `TopicMessageId`. - In `MultiTopicsConsumerImpl#seekAsync`, when the argument is a `TopicMessageId`, find the internal consumer according to the owner topic and pass the argument to it if it exists. - In `ConsumerImpl#seekAsync`, get the inner message ID of the `TopicMessageId` so that now a single-topic consumer can also accept a `TopicMessageId` to seek. Besides the main modifications above, this patch does some refactorings to avoid direct access to `TopicMessageIdImpl`: - Deprecated `getTopicName` method by trimming the partition suffix of the owner topic in `getOriginTopicNameStr`. - Deprecated `getTopicPartitionName` by `getOwnerTopic`. - `getInnerMessageId` cannot be deprecated because we still need to convert `TopicMessageId` to `MessageIdImpl` in many cases (because we cannot get the fields like ledger id). Instead of deprecating it, use `MessageIdImpl.convertToMessageIdImpl` to replace it. - In `convertToMessageIdImpl`, for a customized `TopicMessageId` implementation, use serialization and deserialization to get the `MessageIdImpl` object. ### Verifications Add the following tests to `MultiTopicsConsumerTest`: - `testAcknowledgeWrongMessageId`: verify the correct exceptions are thrown in `acknowledge` APIs - `testSeekCustomTopicMessageId`: verify the new seek semantics for a `TopicMessageId`, including the existing `TopicMessageIdImpl` and the customized implementation by `TopicMessageId#create` ### TODO - Add a standard SerDes class for `TopicMessageId` - Apply `TopicMessageId` into `getLastMessageId` related APIs. - Deprecate the `getInnerMessageId` after PIP-229 is approved.
The pr had no activity for 30 days, mark with Stale label. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
serializing and deserializing is expensive and having different APIs for different use cases are creating a really bad experience for users and I strongly feel we should avoid such APIs and complexity if things can be solved with a simple straight forward change with the same API and without creating bad user experience.
I think we should consider this simple PR without costing performance and API compatibility and confusing usage to the users:
apache#19944
Master issue: apache#18616