Thanks for the proposal, Alex. This sounds like a great improvement. @Yufei As per Quarkus documentation, slow event listeners should be marked with @Blocking so that they are not run on the event loop threads. --
Pierre On Sat, Nov 8, 2025 at 2:14 AM Michael Collado <[email protected]> wrote: > 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 > > > > > > > > > >
