[ 
https://issues.apache.org/jira/browse/JAMES-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17054751#comment-17054751
 ] 

Michael Bailly commented on JAMES-3106:
---------------------------------------

My 2 cent: there is a difference between the action of enabling/disabling a 
feature, and the technical parts that are needed to have the feature working.

Currently, defining a listener (technical endpoint) enables the feature, and 
there is no way to disable it.

One solution could be to set a configuration option "IMAP operations go through 
Spamassassin" that is either tr or false.

> 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]

Reply via email to