PavelZeger commented on issue #25978: URL: https://github.com/apache/pulsar/issues/25978#issuecomment-4663102080
You're right @lhotari , and I'll fix my framing. The examples I gave don't actually leak in Java - duplicates, skipped batch entries, and intermediate chunks all return their permit. So with the invariant holding, today's `resume()` would already flush. And I can't reproduce an actual stuck consumer, so I'll drop that claim. I also can't really justify it on over-granting: Java's r`esume()` already calls `increaseAvailablePermits(cnx, 0)`, which sends only what's owed, not a full batch - so it can't over-grant today either. The only real difference my change can make is when _owed < receiverQueueSize/2_ on resume: current code waits, mine flushes right away. Without a leak that's not a stall, just a small thing - it tops the broker's window back to full the moment you resume instead of letting it refill as messages get consumed. So I'm happy either way: - if you think it's not worth it, I'll close this; - if you think the eager top-up on resume earns its lines, I'll keep it minimal - the small `flushAvailablePermitsToBroker` change plus a `ConsumerImplTest` unit test, framed as "resume tops up the window" rather than a bug fix. WDYT? -- 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]
