Hi Alex, I think it's reasonable to expect event listeners to be thread-safe, and we should document that.
As for event ordering, in most cases I don't think strict ordering matters as long as every event is eventually delivered. However, there are scenarios where ordering is important—for example, if consumers expect events to be persisted in the same order they were dispatched. In such cases, the current behavior can indeed be confusing. Before we moved to the Vert.x service bus, event delivery was ordered. This might be a crazy idea, but what do you think about exposing a configuration option for ordered/unordered event delivery? It could default to the current Vert.x event bus event bus threads, while allowing users to opt into executor based delivery in case ordering doesn't matter for them. Or would that be overkill for addressing this problem? Thanks, Nandor Alexandre Dutra <[email protected]> ezt írta (időpont: 2026. jún. 8., H, 16:12): > > Hi all, > > A recent PR [1] shifted event delivery to a blocking executor, which > has sparked an interesting discussion regarding delivery ordering [2]: > > Previously, we implicitly relied on Vert.x event bus guarantees to > ensure per-listener strict sequential delivery. However, offloading to > a separate executor has compromised these guarantees, leading to two > main issues: > > 1) A given listener can now be invoked concurrently, whereas > previously it wasn't possible. This necessitates making all listener > implementations thread-safe. > > 2) The sequence of events is no longer guaranteed, meaning an "AFTER" > event could potentially be received by a listener before it receives > the corresponding "BEFORE" event. > > It appears we haven't fully addressed this topic before. Per my > recollection, our initial objective was centered on a consistency > guarantee: "at most once" delivery - rather than strict ordering or > thread-safety requirements for listeners. > > I have submitted a new PR [3] that aims to restore the previous > ordering guarantees and eliminate concurrent invocations. > > But I'm interested in your feedback on this topic: maybe it's OK to > give up on strict per-listener ordering? And shouldn't listeners be > thread-safe anyways? > > Regardless of the outcome, I'd suggest we update our documentation to > reflect the exact guarantees we want to offer. > > Thanks, > Alex > > [1]: https://github.com/apache/polaris/pull/4616 > [2]: https://github.com/apache/polaris/pull/4616#discussion_r3365866144 > [3]: https://github.com/apache/polaris/pull/4648
