pulsar-client-go icon indicating copy to clipboard operation
pulsar-client-go copied to clipboard

The behavior of `Seek` is different with Java Client

Open Gleiphir2769 opened this issue 2 years ago • 2 comments

Hi all, I noticed that the behavior of go client Seek is different with Java client, which may confuse the users.

For exmaple, when Seek() invoked.

// Java Client
// seek using the 4th message's id.
consumer.seek(messageIds.get(3));
// consumer will receive the 5th message when startMessageIdInclusive is false
Message<byte[]> msg = consumer.receive();
// Go Client
// seek using the 4th message's id.
consumer.Seek(msgIDs[3])
// consumer will receive the 4th message
msg, err := consumer.Receive(ctx)

In other words, go client create consumer with startMessageIdInclusive=true though the consumer option does not support startMessageIdInclusive now.

Interestingly, the reader options support startMessageIdInclusive but it has different semantics compared with Java Client. This option only takes effect at reader startup but not in Seek() like Java Client. In other words, you will get the 4th message after seeking with the 4th message's id even though your reader option is startMessageIdInclusive=false.

https://github.com/apache/pulsar-client-go/blob/d92fb1407d3d39c8a498dd7c7abdc0bbb3fc7e1a/pulsar/reader.go#L55-L57

I think we should modify the code to make the behavior of Go Client keep same with the Java Client. So I want to start a discuss about it.

The new Seek of consumer and reader should have the following behaviors.

  • startMessageIdInclusive is supported in consumer options and reader options and the default value is false.
  • The consumer and reader should reset their position in id+1 after Seek(id) when startMessageIdInclusive=false.

It should be noted that the above modification will bring breaking change. If the user's code relies on Seek's old behavior, it will cause errors.

Please feel free to leave your comments, Thanks.

Gleiphir2769 avatar Dec 21 '22 08:12 Gleiphir2769