Allow customization of Clock used by the Event Publication Registry

[mokamoto12]

Hi, I have a question.

We understand that the order of events can be important because events can be causal. We also understand that clock synchronization between multiple machines can be skewed.

If the event listener crashes and events are not processed, events from the Event Publication Registry will be resubmitted when the application starts.
But will the events be resubmitted in the same order in which they were submitted by the publisher?

From looking at the JobcEventPublicationRepository, it appears that the events are sorted using PUBLICATION_DATE when the events are retrieved. And it appears that PUBLICATION_DATE is set using the clock of each machine.

If currently the Event Publication Registry is not preserving the order of events and is not resubmitting them in the order submitted by the publisher, is there any plan to support this in the future?

Best regards.

[odrotbohm]

You're right, there's currently no synchronization of clocks going on. Would it help if we optionally picked up a Spring bean of type Clock from the ApplicationContext to determine the publication date?

[odrotbohm]

I've put the option to customize the Clock instance to be used by the Event Publication Registry in place. Let me know if there are other things to consider.

[BartRobeyns]

The Clock only has a precision of milliseconds, and it would be easy for an application to generate two ordered events within the same milliseconds - leading to two identical timestamps in the repository, and no way of determining their relative order. A more precise clock would reduce the possibility of this happening, but not exclude it.

I think the only way to really address this problem is by allowing adding a sequence-number to the stored events.
Without buying into database-specific facilities, a cross-application-instance sequence-generator is of course not easy, but for most use cases probably not necessary either (it's typically about the order of events emitted by a single thread).

Having a default "simple" in-memory sequence-generator bean, initialized at startup time with the largest value in repository, allowing for duplicate sequence-numbers across instances, would serve most purposes already.
Exposing it as a customizable bean would then allow applications to throw in a solution for cross-instance uniqueness, if they have a need to.