Hi Alex, Nandor, My concern with using the Vert.x event bus for calling pluggable code is that in case the process gets stuck it will render the whole server unusable (I think).
The idea of adding a flag for ordered event delivery sounds reasonable to me. Assuming most applications will not require it, it will save some memory (by not having to maintain per-listener queues). Cheers, Dmitri. On Mon, Jun 8, 2026 at 1:36 PM 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 >
