KeyShared consumers with sticky hash range generate backlog with messages not fall within consumer hash range - v2.9.2

[GBM-tamerm]

Describe the bug KeyShared consumers with sticky hash range generate backlog with messages not fall within consumer hash range, and that cause consumers to not receive any messages even for the ones that fall in its range .

To Reproduce Steps to reproduce the behavior:

1. create Keyshared consumer with sticky has range example 35891,35899
2. create producer to generate message with Murmur3_32Hash hashing schema , and the key hash value is outside the consumer range , ex : 35770
3. Consumer will not receive message as expected , however , the message remains in the backlog
4. Now , let producer generate message with key hash fall within the consumer range
5. Consumer still not received the message

Note : IF consumer disconnect and reconnect , it will receive the expected message , however , the same scenario will be repeated for any new messages as long as the consumer has backlog for messages that does not fall within its range

Expected behavior Consumer should have backlog for only messages that fall within its range , and should be able to consume that message

Desktop (please complete the following information): OS: Ubuntu 18.04 Java 8 Pulsar running as systemd service 6 brokers 6 bookies 5 ZK

Additional context Pulsar v2.9.2 No k8 deployment , and client accessing brokers DNS directly without Pulsar proxy.

[codelipenghui]

@GBM-tamerm You can't only have a key hash range [35891,35899] but don't have [0, 35890], [35900, 65535]. The key_shared consumer will not work for this case. If you only want to receive parts of messages, you can use Reader API with specific key hash range.

[GBM-tamerm]

@GBM-tamerm You can't only have a key hash range [35891,35899] but don't have [0, 35890], [35900, 65535]. The key_shared consumer will not work for this case. If you only want to receive parts of messages, you can use Reader API with specific key hash range.

Thanks codellipenghui for reply , the mentioned issue is happening regardless other clients registered to other different ranges or not , that issue does not exist in v2.7.4 , it only appear after we upgrade to v.2.9.2

[github-actions[bot]]

The issue had no activity for 30 days, mark with Stale label.