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 bt...@apache.org on 2020/04/23 08:39:39 UTC

[james-project] 02/02: [ADR] Correction: removing a mailbox listener from the eventBus

This is an automated email from the ASF dual-hosted git repository.

btellier pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/james-project.git

commit ce4f35823c26afd1defae11521f3fce70cefd777
Author: Benoit Tellier <bt...@linagora.com>
AuthorDate: Fri Apr 17 17:23:37 2020 +0700

    [ADR] Correction: removing a mailbox listener from the eventBus
---
 ...oving-configured-additional-mailboxListeners.md | 36 +++++++++++++++++++---
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/src/adr/0026-removing-configured-additional-mailboxListeners.md b/src/adr/0026-removing-configured-additional-mailboxListeners.md
index 3158aaf..b9424b0 100644
--- a/src/adr/0026-removing-configured-additional-mailboxListeners.md
+++ b/src/adr/0026-removing-configured-additional-mailboxListeners.md
@@ -19,17 +19,41 @@ binds to the main event exchange.
 If the user unconfigures the listener, the queue and the binding are still present but not consumed. This results in 
 unbounded queue growth eventually causing RabbitMQ resource exhaustion and failure.
 
+## Vocabulary
+
+A **required group** is a group configured within James additional mailbox listener or statically binded via Guice. We 
+should have a queue for that mailbox listener binded to the main exchange.
+
+A **registered group** is a group whose queue exists in RabbitMQ and is bound to the exchange, independently of its James 
+usage. If it is required, a consumer will consume the queue. Otherwise the queue might grow unbounded.
+
 ## Decision
 
-For rabbitMQ, configuration changes of additional mailbox listeners should be tracked via event sourcing. Event sourcing is 
-desirable as it allows:
+We need a clear consensus and auditability across the James cluster about **required groups** (and their changes). Thus 
+Event sourcing will maintain an aggregate tracking **required groups** (and their changes). Audit will be enabled by 
+adding host and date information upon changes. A subscriber will perform changes (binds and unbinds) in registered groups 
+following the changes of the aggregate.
+
+Event sourcing is desirable as it allows:
  - Detecting previously removed MailboxListener upon start
  - Audit of unbind decisions
  - Enables writing more complex business rules in the future
 
-We need, upon start, to sanitize bindings, and remove the ones corresponding to mailboxListeners that were removed not configured.
+The event sourcing system will have the following command:
+
+ - **RequireGroups** the groups that the **EventBus** is starting with.
+
+And the following events:
 
-The queue should not be deleted to prevent message loss.
+ - **RequiredGroupAdded** a group is added to the required groups.
+ - **RequiredGroupRemoved** a group is removed from the required groups.
+
+Upon start the aggregate will be updated if needed and bindings will be adapted accordingly.
+
+Note that upon failure, registered groups will diverge from required groups. We will add a health check to diagnose 
+such issues. Eventually, we will expose a webadmin task to reset registered groups to required groups.
+
+The queues should not be deleted to prevent message loss.
 
 Given a James topology with a non uniform configuration, the effective RabbitMQ routing will be the one of the latest 
 started James server.
@@ -38,3 +62,7 @@ started James server.
 
 We could also consider adding a webadmin endpoint to sanitize eventBus bindings, allowing more predictability than the
 above solution but it would require admin intervention.
+
+## References
+
+ - [Discussion](https://github.com/linagora/james-project/pull/3280) around the overall design proposed here.


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org