Skip to content

Conversation

@michaeljmarshall
Copy link
Member

@michaeljmarshall michaeljmarshall commented Apr 5, 2024

QueueBrowser connects to Pulsar using a Reader. 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's role 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.

@michaeljmarshall michaeljmarshall self-assigned this Apr 5, 2024
Test might fail. I couldn't figure out
how to run it locally, so I might need
to iterate on the remote CI.
Copy link
Contributor

@nicoloboschi nicoloboschi left a comment

Choose a reason for hiding this comment

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

LGTM

.readerName("jms-queue-browser-" + UUID.randomUUID())
.startMessageId(seekMessageId)
.startMessageIdInclusive()
.subscriptionName(queueSubscriptionName)
Copy link
Collaborator

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

The merge from upstream/master broke
the test's compilation. I am not
sure if this test passes yet.
@michaeljmarshall
Copy link
Member Author

@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?

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.

3 participants