From 74b6f1ea844b31b10362de46b0db05b1aca855b8 Mon Sep 17 00:00:00 2001 From: d040506 Date: Wed, 23 Oct 2024 14:31:18 +0200 Subject: [PATCH 1/4] Updated the default behaviour of the messaging error handler --- java/messaging.md | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/java/messaging.md b/java/messaging.md index bf5fda97f..1b1b32ade 100644 --- a/java/messaging.md +++ b/java/messaging.md @@ -679,6 +679,44 @@ private void handleError(MessagingErrorEventContext ctx) { ctx.setResult(true); // acknowledge } } +``` + + In the multitenant application, there may be scenarios in which the client is not yet or no longer available. In this case, the message cannot be processed for the client because the client context is not available. In this case, the standard error handler acknowledges the message to prevent it from getting stuck in the message sequence. To change this behavior, the custom error handler from the example above can be extended by checking the exception type of the unknown tenant. + + +```java +@On(service = "messaging") +private void handleError(MessagingErrorEventContext ctx) { + + String errorCode = ctx.getException().getErrorStatus().getCodeString(); + if (errorCode.equals(CdsErrorStatuses.NO_ON_HANDLER.getCodeString()) || + errorCode.equals(CdsErrorStatuses.INVALID_DATA_FORMAT.getCodeString())) { + // error handling for infrastructure error + ctx.setResult(false); // no acknowledgement + + } else if (errorCode.equals(CdsErrorStatuses.TENANT_NOT_EXISTS.getCodeString())) { + // error handling for unknown tenant context + + // tenant of the received message + String tenant = ctx.getTenant(); + + // receieved message + Map headers = ctx.getMessageHeaders(); + Map message = ctx.getMessageData(); + + ctx.setResult(true); // acknowledge + } else { + // error handling for application errors + + // how to access the event context of the raised exception: + // ctx.getException().getEventContexts().stream().findFirst().ifPresent(e -> { + // String event = e.getEvent()); + // String payload = e.get("data")); + // }); + + ctx.setResult(true); // acknowledge + } +} ``` ::: warning _❗ Warning_ From eadc63d8119f2568f9b33047580b3ff7502ed5e6 Mon Sep 17 00:00:00 2001 From: Dietrich Mostowoj <34100436+dimamost@users.noreply.github.com> Date: Mon, 28 Oct 2024 09:53:08 +0100 Subject: [PATCH 2/4] Update messaging.md --- java/messaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/java/messaging.md b/java/messaging.md index 1b1b32ade..b9e5a094e 100644 --- a/java/messaging.md +++ b/java/messaging.md @@ -681,7 +681,7 @@ private void handleError(MessagingErrorEventContext ctx) { } ``` - In the multitenant application, there may be scenarios in which the client is not yet or no longer available. In this case, the message cannot be processed for the client because the client context is not available. In this case, the standard error handler acknowledges the message to prevent it from getting stuck in the message sequence. To change this behavior, the custom error handler from the example above can be extended by checking the exception type of the unknown tenant. +In the multitenant application, there may be race conditions in the subscription process. In this case, the message cannot be processed for the tenant because the tenant context is not available. In this case, the standard error handler acknowledges the message to prevent it from getting stuck in the message sequence. To change this behavior, the custom error handler from the example above can be extended by checking the exception type of the unknown tenant. ```java From 8514b04ad42cd9840df5688e4a3acb2ffe0d79de Mon Sep 17 00:00:00 2001 From: Mahati Shankar <93712176+smahati@users.noreply.github.com> Date: Tue, 17 Dec 2024 16:43:05 +0100 Subject: [PATCH 3/4] Update java/messaging.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: René Jeglinsky --- java/messaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/java/messaging.md b/java/messaging.md index b9e5a094e..da74a3f3d 100644 --- a/java/messaging.md +++ b/java/messaging.md @@ -700,7 +700,7 @@ private void handleError(MessagingErrorEventContext ctx) { // tenant of the received message String tenant = ctx.getTenant(); - // receieved message + // received message Map headers = ctx.getMessageHeaders(); Map message = ctx.getMessageData(); From f9717fb81c0f9d120111b1af32449964a22d3546 Mon Sep 17 00:00:00 2001 From: BraunMatthias <59841349+BraunMatthias@users.noreply.github.com> Date: Tue, 17 Dec 2024 17:14:56 +0100 Subject: [PATCH 4/4] Update java/messaging.md --- java/messaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/java/messaging.md b/java/messaging.md index da74a3f3d..13f75edf3 100644 --- a/java/messaging.md +++ b/java/messaging.md @@ -681,7 +681,7 @@ private void handleError(MessagingErrorEventContext ctx) { } ``` -In the multitenant application, there may be race conditions in the subscription process. In this case, the message cannot be processed for the tenant because the tenant context is not available. In this case, the standard error handler acknowledges the message to prevent it from getting stuck in the message sequence. To change this behavior, the custom error handler from the example above can be extended by checking the exception type of the unknown tenant. +In a multi-tenant setup with several microservices, messages of a tenant not yet subscribed to the own microservice would be already received from the message queue. In this case, the message cannot be processed for the tenant because the tenant context is not yet available. By default, the standard error handler still acknowledges the message to prevent it from getting stuck in the message sequence. To change this behavior, the custom error handler from the example above can be extended by checking the exception type of the unknown tenant. ```java