-
Notifications
You must be signed in to change notification settings - Fork 369
Description
Expected behavior
I would expect if I peek the same message via PeekMessages, that the returned message would contain the same set of properties each time
Func:
PeekMessages(utils.TopicName, string, int) ([]*utils.Message, error)
Properties:
properties := make(map[string]string)
Actual behavior
Instead the properties returned are not consistent, often not including the "publish-time" properties (and others)
Specifically discussing "publish-time", some calls to peek a message will contain this properties, others won't, even if the returned message has the same Id.
This is because the loop setting the properties exits whenever it sees the batch header and it is looping over all headers in a non-deterministic way
- Sometimes it'll see the batch header before it sees other headers and exit before setting all properties
- Sometimes it'll see all other headers first before it sees the batch header, which results in correctly setting all properties
Steps to reproduce
Create topic
Publish messages to that topic
Create subscription (don't consume any messages)
Repeatedly call PeekMessages on this topic
pulsarAdminClient.Subscriptions().PeekMessages(partition, subscriptionName, 1)
On each invocation, look for the "publish-time" property
message.Properties["publish-time"]
You'll see if it often not set, as this is based on return order + map ordering, it may take a few calls. If you run this in a tight loop you'd expect to see this near immediately.
System configuration
Tested and presented in the following config setup:
Config 1:
- github.com/apache/pulsar-client-go v0.14.0
- apachepulsar/pulsar:3.0.2
Config 2:
- github.com/apache/pulsar-client-go v0.16.0
- apachepulsar/pulsar:4.0.6
In both cases I was running in standalone mode
Comment
This is due to what I assume is a simple bug, I'll raise a simple PR to fix the issue.
The PR is more to demonstrate a potential fix, I'm happy if someone writes their own patch if there is a better fix for this issue.
I've tested my PR does not demonstrate the behaviour I've described above