When calling prepare or execute on a connection, a monitor is started on that connection which is configured to be removed when it receives a reply using the created alias. However it does not always receive a reply using that alias, which can lead to a resource leak where monitors are created and never removed.
This is mostly (only?) a problem when calling prepare on a long running connection from a long running process when the prepared query already is in the cache, because then the connection does not send a reply using the alias. The leaked monitors eventually takes up enough memory to crash the application. In my case, after a few hours.
When calling prepare or execute on a connection, a monitor is started on that connection which is configured to be removed when it receives a reply using the created alias. However it does not always receive a reply using that alias, which can lead to a resource leak where monitors are created and never removed.
This is mostly (only?) a problem when calling prepare on a long running connection from a long running process when the prepared query already is in the cache, because then the connection does not send a reply using the alias. The leaked monitors eventually takes up enough memory to crash the application. In my case, after a few hours.
Example before fix:
By explicitly demonitoring when a reply is not guaranteed, the resource leak is fixed.
Example after fix: