NiuBlibing commented on issue #23944: URL: https://github.com/apache/pulsar/issues/23944#issuecomment-2709361078
> If your application frequently encounters OOM errors or crashes, you should monitor and address those issues within your application, right? Agreed, detecting bugs and fixing them is the preferred option in most cases. However, I've come across a scenario where certain payloads cause third-party libraries to generate oom (e.g. processing complex files that can't be directly determined by file size), and it's not easy to go deeper into the third-party libraries and rewrite the relevant logic. I'd like to be able to handle this with the crash retry mechanism in the message queue so that these errors are handled transparently and don't introduce extra work. > A key question to consider is: How does the broker determine that messages have been delivered to the application? When messages are dispatched from the broker to the consumer, they might just be placed in the consumer’s receiverQueue, but the application may not have actually received them yet. Maybe it's also not easy for pulsar to deal the logic in broker without extra performance overload. -- 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]
