You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Benoit Tellier (Jira)" <se...@james.apache.org> on 2021/09/04 05:35:00 UTC
[jira] [Closed] (JAMES-3106) Unbinding a RabbitMQ enventGroup don't
work.
[ https://issues.apache.org/jira/browse/JAMES-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benoit Tellier closed JAMES-3106.
---------------------------------
Resolution: Fixed
To disable it explicitly unbind things in RabbitMQ admin web interface
> Unbinding a RabbitMQ enventGroup don't work.
> --------------------------------------------
>
> Key: JAMES-3106
> URL: https://issues.apache.org/jira/browse/JAMES-3106
> Project: James Server
> Issue Type: New Feature
> Components: mailbox, rabbitmq
> Reporter: Benoit Tellier
> Priority: Major
>
> *Problem:*
> {code:java}
> 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
> {code}
> 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:
> {code:java}
> curl -XPOST htt://ip:port/eventBus/workQueues?removeUnused
> {code}
> But I don't like relying on admins to remember to call it...
> Thoughts on this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org