Major Description
Problem:
Given a running James cluster configured with additional listenerA
When I do a rolling configuration change to remove listenerA
Then James keeps posting events in the queue corresponding to listenerA without consuming it
To summarize we can not remove additional listeners properly even with a restart.
Impact: the queue keeps growing indefinitly eventually causing a rabbitMQ failure.
Temporary workaround:
Upon such reconfiguration an admin needs to manually delete the corresponding binding using rabbitmq admin interface.
Long term solution:
We need to provide an easier way to clean this up.
- Deleting all mailboxEvent bindings upon stop is not an option as:
- other james servers depends on it
- james might not be stopped in a gracefull way
- James could be sanitizing existing bindings upon start (removing the extra ones) but I'm worry about uneven configuration clusters. (serverA have the additional listener, not serverB)
We could as well provide a cleanup endpoint for the admin to call once the rolling adoption is done. Something like:
curl -XPOST htt://ip:port/eventBus/workQueues?removeUnused
But I don't like relying on admins to remember to call it...
Thoughts on this?