I agree with the thread safety requirement and the reasoning around ordering.
>From a UX perspective, I'd prefer to keep ordering as the only behavior now and only introduce unordered delivery if we find a real performance need for it. This preserves the behavior users had before PR #4616 and avoids premature optimization. Yufei On Mon, Jun 8, 2026 at 10:36 AM Alexandre Dutra <[email protected]> wrote: > Hi Nándor, > > I agree that listeners should be thread-safe, and that this should be > clearly documented. > > Re: event ordering. My intuition is that you are right: most listeners > don't need that. The persistence listener, for instance, doesn't > collate events and therefore doesn't need to receive "before" events > before the "after" ones. They will get persisted out of order, but > once persisted, what really matters is the event timestamp. I think > the same applies for the CloudWatch listener. However, consider for > instance a Kafka listener/producer: out-of-order events might be > problematic depending on the Kafka consumer expectations. > > Your idea is not that crazy imho: I think it should be fairly simple > to put event ordering behind a feature flag. > > I'm curious to hear what others think though. > > Thanks, > Alex > > On Mon, Jun 8, 2026 at 5:46 PM Nándor Kollár <[email protected]> wrote: > > > > 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 >
