lhotari commented on issue #25978: URL: https://github.com/apache/pulsar/issues/25978#issuecomment-4659738771
> But it's the wrong thing to do on resume. If, right when you resume, the consumer owes fewer permits than that and the broker has no permits left, then resume sends nothing. I don't think that it's completely wrong and I don't see directly why the existing behavior would be causing the consumer to get stuck. However I do agree that it would make sense to send flow permits for all available permits after resuming the consumer. When pause is called, the available permits should eventually get in the state where the consumer has `available permits >= receiver queue size / 2`. There must be other underlying bugs if the current logic doesn't resume the consumer. > When does this happen? Mostly when not every delivered message bumps the permit count by one (for example, duplicate or chunk fragments that get thrown away). In that case the owed count can end up below the threshold while the broker has already sent everything it was allowed to. It seems that there are existing bugs if this happens. The permits handling should be only about what has been sent or received on the wire. If the broker sends duplicates, it shouldn't matter. Permit leaks would also impact other use cases, not just pause/resume. That's why finding and fixing the root cause is important. In permit accounting the invariant is `brokerInFlight + queuedAtClient + availablePermits == receiverQueueSize`. A consumer is only truly stuck when the broker has 0 permits, the client queue is empty, and `available permits < receiverQueueSize / 2`. If the invariant holds, broker-idle + empty-queue forces `available == receiverQueueSize`, so resume *would* flush. A real stall therefore requires that this invariant is broken. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
