-
Notifications
You must be signed in to change notification settings - Fork 21
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
Configure QueueBrowser's pulsar reader with subscription name #118
base: master
Are you sure you want to change the base?
Configure QueueBrowser's pulsar reader with subscription name #118
Conversation
Test might fail. I couldn't figure out how to run it locally, so I might need to iterate on the remote CI.
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.
LGTM
@@ -1546,6 +1546,7 @@ private Reader<?> createReaderForBrowserForNonPartitionedTopic( | |||
.readerName("jms-queue-browser-" + UUID.randomUUID()) | |||
.startMessageId(seekMessageId) | |||
.startMessageIdInclusive() | |||
.subscriptionName(queueSubscriptionName) |
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.
this is probably not going to work
because:
- the name of the subscription is unique, and you are going to use an existing name, the behavior is unpredictable (you have a Durable and a NonDurable subscription with the same name)
- you cannot run to QueueBrowsers concurrenly
II suggest to make this name configurable at PulsarConnectionFactory level, this is basically the name of the tool that you are using to monitor the topic and not the application itself.
Or alternatively we have to add a uuid suffix to this name:
- the name is still bound to the original queueSubcriptionName
- the name is unique
…rowser-reader-sub
The merge from upstream/master broke the test's compilation. I am not sure if this test passes yet.
@eolivelli - this passes tests locally now, for me. My one higher level concern is whether datastax/pulsar#246 will break any other components that rely on readers. Does the JMS implementation for transactions have any dependency on them? |
QueueBrowser
connects to Pulsar using aReader
. A reader looks like a normal consumer from the pulsar protocol perspective. It is associated with a subscription name, which is later used by the authorization framework to determine if the client'srole
has permission to perform the action on the subscription, even though the subscription is not technically used. Therefore, we need to make sure we can configure the subscription name if we're connecting as a non-admin role.