[GitHub] [pulsar] sijie commented on issue #5278: Fixed reader cursor seek with disconnection
sijie commented on issue #5278: Fixed reader cursor seek with disconnection URL: https://github.com/apache/pulsar/pull/5278#issuecomment-578371324 @bsideup sorry. if they are in the same subscription, it is expected that all consumers in the same subscription to reset to the new cursor position if the cursor is reset from a correctness perspective. I see what can be improved here is when the broker disconnects the consumers, it can disconnect the *active* consumers only. For exclusive/failover subscription, it will only reset the consumer that is currently active. This seems to be a correct fix. @codelipenghui @merlimat what do you think? 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: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [pulsar] sijie commented on issue #5278: Fixed reader cursor seek with disconnection
sijie commented on issue #5278: Fixed reader cursor seek with disconnection URL: https://github.com/apache/pulsar/pull/5278#issuecomment-577982291 @bsideup thank you for your updates? Do these N sessions belong to one subscription? 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: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [pulsar] sijie commented on issue #5278: Fixed reader cursor seek with disconnection
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: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [pulsar] sijie commented on issue #5278: Fixed reader cursor seek with disconnection
sijie commented on issue #5278: Fixed reader cursor seek with disconnection URL: https://github.com/apache/pulsar/pull/5278#issuecomment-551442260 actually moved to 2.4.3 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: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [pulsar] sijie commented on issue #5278: Fixed reader cursor seek with disconnection
sijie commented on issue #5278: Fixed reader cursor seek with disconnection URL: https://github.com/apache/pulsar/pull/5278#issuecomment-551440754 Moved this to 2.5.0 since I think it requires some more discussions about the side effect of this change. 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: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [pulsar] sijie commented on issue #5278: Fixed reader cursor seek with disconnection
sijie commented on issue #5278: Fixed reader cursor seek with disconnection URL: https://github.com/apache/pulsar/pull/5278#issuecomment-550258822 @merlimat I wasn't sure how is the ordering guaranteed if we don't clean up the cached message. Can you clarify it? 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: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [pulsar] sijie commented on issue #5278: Fixed reader cursor seek with disconnection
sijie commented on issue #5278: Fixed reader cursor seek with disconnection URL: https://github.com/apache/pulsar/pull/5278#issuecomment-545826384 @merlimat If we don't disconnect the consumers, how do consumers reset their state? e.g. pending queue, acknowledgement, and etc. 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: us...@infra.apache.org With regards, Apache Git Services
