Description
It sometimes happens that php processes leak memory.
This might be in app code, but it might be as well in a deeply nested dependency.
And finding out where the leak comes from is often complex and time consuming; sometimes just impossible.
Sometimes, the leak is not in memory usage but in file handles, or db connections, etc...
So far, the best way to avoid a long-running message consumer process with memory leaks from bringing down the server is to either use a safe value for memory_limit in php.ini, or use the -m cli flag, and then rely on the watchdog to restart the 'killed' process.
We also allow to specify a timeout in number of seconds as well as number of consumed messages (which is not deterministic alas), which helps when we are leaking resources.
An arguably better solution would be to allow a 'garbage collection' routine, made available by the app developer, to be called every N seconds from the message-consumption loop.
This way there would be no need to kill the consumer process, and the cleanup of leaked resources could be much more granular.