[
https://issues.apache.org/jira/browse/JAMES-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
René Cordier updated JAMES-3142:
--------------------------------
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 \{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.
This happened on UPN when we tried removing the SpamAssassin listener.
*Solution*
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)
was:
*Problem:*
{code:java}
{code}
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.
This happened on UPN when we tried removing the SpamAssassin listener.
*Solution*
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)
> Removing an additional mailbox listener
> ---------------------------------------
>
> Key: JAMES-3142
> URL: https://issues.apache.org/jira/browse/JAMES-3142
> Project: James Server
> Issue Type: Improvement
> Reporter: René Cordier
> Priority: Major
>
> *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 \{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.
> This happened on UPN when we tried removing the SpamAssassin listener.
> *Solution*
> 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)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
