Provided a better solution for reading dead outbox entries #1940
Conversation
| } | ||
|
|
||
| private Optional<Predicate> createOutboxFilters(CdsRuntime runtime) { | ||
| List<OutboxService> outboxServices = runtime.getServiceCatalog().getServices(OutboxService.class) |
There was a problem hiding this comment.
what about iterating the persistent outboxes from application configuration (outboxConfigs)+ the known defaults? INMEMORY_NAME would not be required.
There was a problem hiding this comment.
@BraunMatthias If an outbox has the default configuration, iterating over the configurations doesn't return the specific config for an outbox. I observed this while testing the code; in this case no outbox can be found and hence no dead entries are read at all.
There was a problem hiding this comment.
This might be only true for the two default outboxes which needed to be explicitly named here. But what happens in 398 for those?
| Predicate where = null; | ||
| for(OutboxService service : outboxServices) { | ||
| OutboxServiceConfig config = outboxConfigs.getService(service.getName()); | ||
| Predicate targetPredicate = CQL.get(Messages.TARGET).eq(service.getName()).and(CQL.get(Messages.ATTEMPTS).ge(config.getMaxAttempts())); |
There was a problem hiding this comment.
why do we need to filter by individual outbox and then OR the condition meeting all outboxes?
There was a problem hiding this comment.
@BraunMatthias Every outbox can have its own configuration for maxAttempts. To read only the dead entries per outbox, this filter is required.
There was a problem hiding this comment.
same reason - I just overlooked this aspect
Co-authored-by: BraunMatthias <[email protected]>
| This filtering can't be done on the database since the maximum number of attempts is only available from the CDS properties. | ||
|
|
||
| To ensure that only dead outbox entries are returned when reading `DeadOutboxMessages`, the following code provides the handler for the `DeadLetterQueueService` and the `@After-READ` handler that filters for the dead outbox entries: | ||
| Filtering the dead entries is done by adding by adding an appropriate `where`-clause to `READ`-queries on the outbox message entries which reached maximum number of retries. The following code provides an example handler implementation defining this behaviour for the `DeadLetterQueueService`: |
There was a problem hiding this comment.
| Filtering the dead entries is done by adding by adding an appropriate `where`-clause to `READ`-queries on the outbox message entries which reached maximum number of retries. The following code provides an example handler implementation defining this behaviour for the `DeadLetterQueueService`: | |
| Filtering the dead entries is done by adding an appropriate `where`-clause to all `READ`-queries which covers all outbox message entries with maximum number of retries. The following code provides an example handler implementation defining this behaviour for the `DeadLetterQueueService`: |
| } | ||
|
|
||
| private Optional<Predicate> createOutboxFilters(CdsRuntime runtime) { | ||
| List<OutboxService> outboxServices = runtime.getServiceCatalog().getServices(OutboxService.class) |
There was a problem hiding this comment.
This might be only true for the two default outboxes which needed to be explicitly named here. But what happens in 398 for those?
No description provided.