sijie commented on issue #5278: Fixed reader cursor seek with disconnection URL: https://github.com/apache/pulsar/pull/5278#issuecomment-575699228 --- @codelipenghui @jiazhai @merlimat without sending a close consumer command to the client, the client will not clean the pre-fetched items in its queue. Hence resetting a cursor can result in dispatching duplicated items and unexpected behavior. For example, in the following sequence, 1) a consumer is receiving messages. it already pre-prefetches 5 messages (1, 2, 3, 4, 5). 2) it only calls `receive` once. It receives a message `1`. there are 4 messages in the queue. 3) it calls `reset` to reset to message `0`. it is expecting to receive `1` for next `receive` call. but since 2-5 are still in the client cache. when it calls `receive`, it will receive `2`. IMO this violates the guarantee that pulsar provides. Looking more into this issue and checking the current implementation, it seems the current implementation seems to be ok and shouldn't have any side-effects on connections. So I would like to step back and understand a bit more about the *problematic* behavior driving the motivation of this change. @bsideup you mentioned the followings in your previous comment: ``` Since Liiklus is not using Pulsar's offset storage, it performs "seek" on every partition, and it causes the other connections to disconnect, and, when they connect.... it seeks again 😂 ``` Can you clarify what do you observe "it causes the other connections to disconnect"? As far as I know, "close consumer" will not close a multiplexed connection. I am trying to understand what you have observed before.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
