I was curious regarding the most common (or recommended) implementations of disruptor about the journaling step. And the most common questions of mine are:
- how it is actually implemented (by example)?
- Is it wise to use JPA?
- What DB is commonly used (by the community that has already implement projects with disruptor)?
- Is it wise to be used at the intermediate handlers (of EventProcessors) so the State of each message should be saved, rather than before and after the business logic process?
By the way (I am sorry, I know this is not related with the journalling step), what is the right way to delete a message from the RingBuffer during an eventHandler process (assuming that the message is dead/expired and should be removed by the whole procedure). I was wondering something similar as the Dead Letter Channel pattern.
Cheers!
The Disruptor is usually used for low latency, high throughput processing. E.g. millions of messages with a typical latency in the hundreds of micro-seconds. As very few databases can handle this sort of rate of updates with reasonably bounded delays, journaling is often done to a raw file with replication to a second (or third) system.
For reporting purposes, a system reads this file or listens to messages and updates a database as quickly as it can but this is taken out of the critical path.
An entry is dead in the ring buffer when every event processor has processed it.
The slot a message uses is not available until every event processor has processed it and all the message before it. Deleting a message would be too expensive, both in terms of performance and impact on the design
Every event processors sees every message. As this happens concurrently, there is little cost in doing this, but it quite normal for event processors to ignore messages as a result. (possibly most messages)