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 2020/03/07 15:12:00 UTC
[jira] [Updated] (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 updated JAMES-3106:
----------------------------------
Description:
*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?
was:
*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}
Thoughts on this?
> 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