This message was deleted.
# general
s
This message was deleted.
a
What’s the subscription type
a
key_shared
a
I will recommend to capture the
stats
- https://pulsar.apache.org/docs/next/administration-stats/ and monitor the
availablePermits
a
Thanks. I'll try it.
a
I documented something really important about key shared: https://pulsar.apache.org/docs/3.0.x/concepts-messaging/#preserving-order-of-processing
thankyou 1
Key Shared Subscription type guarantees a key will be processed by a single consumer at any given time. When a new consumer is connected, some keys will change their mapping from existing consumers to the new consumer. Once the connection has been established, the broker will record the current read position and associate it with the new consumer. The read position is a marker indicating that messages have been dispatched to the consumers up to this point, and after it, no messages have been dispatched yet. The broker will start delivering messages to the new consumer only when all messages up to the read position have been acknowledged. This will guarantee that a certain key is processed by a single consumer at any given time. The trade-off is that if one of the existing consumers is stuck and no time-out was defined (acknowledging for you), the new consumer won’t receive any messages until the stuck consumer resumes or gets disconnected.
That requirement can be relaxed by enabling
allowOutOfOrderDelivery
via the Consumer API. If set on the new consumer, then when it is connected, the broker will allow it to receive messages knowing some messages of that key may be still be processing in other consumers at the time, thus order may be affected for that short period of adding a new consumer.
This may be the issue
a
Thanks a million
a
Thanks! Currently we also trying to figure out the reason behind consumers becoming stuck. As far as I understand the behaviour that we observe is the following: * read position was associated with consumer by the broker * consumer does not receive messages up to the read position * when we manually restart the consumer, previously recorded read position becomes irrelevant as consumer is closed, and newly created consumer receives messages This happens rarely, supposedly when there were short-lived issues with network, as we see logs about reconnection, but it would be nice to avoid the last step. At the moment we have acknowledgement timeout disabled, as from the business logic point of view there is no real need to resend messages unless there was a negative acknowledgement. If we enable ackTimeout, we would need to additionally figure out where received message should be processed or not, as it already was processed before, which seems cumbersome.
m
👍 1