With asynchronous event listeners, is there a guarantee of delivery to all listeners for a given event? The downside of synchronous listeners is that everything is serial, but also if something fails, processing stops. This feels important for auditing purposes, though less important for other cases.
Mike On Fri, Nov 7, 2025 at 2:28 PM Yufei Gu <[email protected]> wrote: > Thanks, Alex and Adam. One concern I have is about the shared runtime > thread pool. > Since the Vert.x event bus runs on event-loop threads that are also used by > Quarkus’ reactive REST endpoints, could blocking or slow event listeners > potentially stall REST requests and impact latency? > > Yufei > > > On Fri, Nov 7, 2025 at 11:25 AM Adam Christian < > [email protected]> wrote: > > > I think that this would be a great enhancement. Thanks for proposing it! > > > > The only concern I would have is around fault-tolerance. From what I can > > tell, from the Quarkus documentation, the Quarkus event bus uses Vert.x > > EventBus which does not guarantee message delivery if failure of part of > > the event bus occurs [1]. However, we can easily make sure that we use > > Quarkus's SmallRye Fault Tolerance [2]. Is my rough understanding inline > > with your proposal? > > > > Go community, > > > > Adam > > > > [1]: https://vertx.io/docs/apidocs/io/vertx/core/eventbus/EventBus.html > > [2]: https://quarkus.io/guides/smallrye-fault-tolerance > > > > On Fri, Nov 7, 2025 at 11:49 AM Alexandre Dutra <[email protected]> > wrote: > > > > > Hi all, > > > > > > I'd like to propose an enhancement to our existing events feature: the > > > ability to support multiple listeners. > > > > > > Currently, only a single listener can be active at a time, which is > > > quite limiting. For example, we might need to persist events for audit > > > purposes and simultaneously send them to a message queue for > > > optimization. With the current setup, this isn't easily achievable. > > > > > > While a composite listener could be created, it feels like a less > > > elegant solution, and the delivery would be strictly serial, > > > processing one listener after another. > > > > > > My suggestion is to leverage Quarkus internal event bus [1]: > > > > > > 1) There will be one central event emitter responsible for publishing > > > events to the bus. > > > > > > 2) We will have zero to N listeners, each independently watching the > > > event bus for relevant events. They will be discovered by CDI. > > > > > > 3) We could apply filters to each listener, e.g. listener A listens > > > for event types X and Y, listener B only listens to event type Y. > > > > > > 4) This approach would ensure fully asynchronous delivery of events to > > > all interested listeners. > > > > > > 5) Fault-tolerance could also be easily implemented (event delivery > > > retries, timeouts, etc.). > > > > > > What do you all think? > > > > > > Thanks, > > > Alex > > > > > > [1]: https://quarkus.io/guides/reactive-event-bus > > > > > >
