The (maybe imaginary) scenario I had in mind was: * your business logic depends on exact buffering behavior (otherwise you wouldn't be using "final") * you want to bound how much memory the app uses * you discover that in practice the app needs more memory than your bound
It seems like in a situation like this, you would like a graceful shutdown with a clear message so that you can reconsider your options. * maybe you take a look at your metrics and discover that you can decrease the window grace period, thereby relieving memory pressure * maybe you change the environment so you can allocate more memory to the task Unless you are using IQ or doing something time-sensitive like high-frequency trading, shutting the app down for short periods of time when it's misbehaving should be acceptable. Having hard failures like this can actually be more operationally friendly than grey failures like frequent GC or apps stealing memory from each other. But of course, it depends on the situation. There is a possibility of implementing more complex behaviors, such as pausing some tasks to allow others to flush more work, but I don't think we need to think about that right now. That was all for context. At the end of the day, if we don't think we need the "graceful shutdown" mode, I'd rather not implement it. [ Full content available at: https://github.com/apache/kafka/pull/5567 ] This message was relayed via gitbox.apache.org for [email protected]
