[
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: [email protected]
For additional commands, e-mail: [email protected]
