Trần Tiến Đức created MAILBOX-386:
-------------------------------------
Summary: [EventDeadLetter] Data races upon removal
Key: MAILBOX-386
URL: https://issues.apache.org/jira/browse/MAILBOX-386
Project: James Mailbox
Issue Type: New Feature
Reporter: Trần Tiến Đức
Data race can occur upon failed event reprocessing - the listener re-adds the
event in dead-letter then the reprocessing-service removes it.
See
https://github.com/linagora/james-project/pull/2227/files/88268be7fd26ee0ce8d076b57ed4715f22db48ff..4be43d8841bad4adcb18921ed6e1e42f5c19b0c4#r263267692
Proposed fix:
Create a InsertionId leveraging UUID
Transfort the deadletter API into
{code:java}
public interface EventDeadLetters {
Mono<Void> store(Group registeredGroup, Event failDeliveredEvent,
InsertionId insertionId);
Mono<Void> remove(Group registeredGroup, InsertionId insertionId);
Mono<Event> failedEvent(Group registeredGroup, InsertionId insertionId);
Flux<InsertionId> failedEventIds(Group registeredGroup);
Flux<Group> groupsWithFailedEvents();
}
{code}
With that API we can build a data-race free reprocessing API
We will:
- InMemory support + contract tests
- Review Cassandra table structure (PK insertionId, serialized event column)
- Handle versioning in the reprocessing service and re-enable the commented
test.
- Unit tests will need to handle this new insertionId
Also we need to log the correspondance between eventId and insertionId within
the event bus for allowing log-deadletter correlation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
