-
Notifications
You must be signed in to change notification settings - Fork 43
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
Cannot seek on partitioned topic #213
Comments
It's not the expected behavior. In Java client, a
Currently, you can seek to a very large timestamp to simulate |
Hi @BewareMyPower - I'm not sure I follow, but are multi-topic consumers entangled in this discussion? In the example above, all I am doing is making a single topic and then trying to seek latest on it. Isn't that exactly the behaviour being discussed here: apache/pulsar#3643 (comment)
Will swap over to doing this in the interim, cheers :) |
It's always confusing in Pulsar when topics and partitions are mentioned. I'd rather to mention "topic" as "non-partitioned topic" or "a partition of a partitioned topic". In Java client, a multi-topics consumer could also be created when the subscribed topic is a single partitioned topic. |
### Motivation See apache/pulsar-client-python#213 ### Modifications Add a new `forEachValue` overload that allows users to count the number of rest running tasks through `SharedFuture` to `SynchronizedHashMap`. Leverage this overload in seek operations when the argument is a timestamp, or a MessageId that represents earliest or latest. When the argument is a MessageId whose `getTopicName()` method returns a correct topic name, seek on the internal consumer of that topic. Add `testMultiTopicsSeekAll` and `testMultiTopicsSeekSingle` to `ConsumerSeekTest` to cover these cases.
### Motivation See apache/pulsar-client-python#213 ### Modifications Add a new `forEachValue` overload that allows users to count the number of rest running tasks through `SharedFuture` to `SynchronizedHashMap`. Leverage this overload in seek operations when the argument is a timestamp, or a MessageId that represents earliest or latest. When the argument is a MessageId whose `getTopicName()` method returns a correct topic name, seek on the internal consumer of that topic. Add `testMultiTopicsSeekAll` and `testMultiTopicsSeekSingle` to `ConsumerSeekTest` to cover these cases.
### Motivation See apache/pulsar-client-python#213 ### Modifications Add a new `forEachValue` overload that allows users to count the number of rest running tasks through `SharedFuture` to `SynchronizedHashMap`. Leverage this overload in seek operations when the argument is a timestamp, or a MessageId that represents earliest or latest. When the argument is a MessageId whose `getTopicName()` method returns a correct topic name, seek on the internal consumer of that topic. Add `testMultiTopicsSeekAll` and `testMultiTopicsSeekSingle` to `ConsumerSeekTest` to cover these cases.
### Motivation See apache/pulsar-client-python#213 ### Modifications Add a new `forEachValue` overload that allows users to count the number of rest running tasks through `SharedFuture` to `SynchronizedHashMap`. Leverage this overload in seek operations when the argument is a timestamp, or a MessageId that represents earliest or latest. When the argument is a MessageId whose `getTopicName()` method returns a correct topic name, seek on the internal consumer of that topic. Add `testMultiTopicsSeekAll` and `testMultiTopicsSeekSingle` to `ConsumerSeekTest` to cover these cases.
As per apache/pulsar#3643, it seems pulsar should support seeking on partitioned topics.
This functionality seems partially missing in the C++ and python clients.
Reproduction
First, run a pulsar standalone instance:
Ensure you have pulsar client and httpx dependencies, and then run the following code:
Expected Behaviour
Seeking should work across partitions. A seek to latest should take you to latest across partitions. Seeking by a MessageId (which contains a partition number) should seek that partition.
Curiously, passing in an explicit integer timestamp doesn't raise this exception, which seems to disagree with the doco that seeking is just not supported.
Workarounds
Is there any way in the provided python API to seek on a per-partition basis as a workaround?
The text was updated successfully, but these errors were encountered: