bad pattern to fire a sync and async event at same time?

[William Burke]

I'm assuming this behavior for firing events:

* If you do event.fire() only subscribers that @Observes are called

* If you do event.fireAsync() only subscribers that @ObservicesAsync are called

Is it a bad pattern to do both event.fire() and event.fireAsync()?  That way subscribers that want the event synchronously can do their thing and subscribers that want it asynchronously do their thing?

--

Bill Burke

IBM

[Eric Deandrea]

I’ve never actually liked the design in the first place. Shouldn’t it be up to the subscriber to decide how they want to handle the event (async vs sync)? Different subscribers to an event may want to handle it differently. Why should the publisher need to decide how the consumer should handle the event?

Eric Deandrea

Java Champion

Senior Principal Software Engineer

Quarkus | LangChain4j | Docling-Java

Red Hat

edea...@redhat.com    M: 603.453.5840

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjRoDB1f13SydXUHViUzYeRcctkiS4upmWaVMttgFx5pjA%40mail.gmail.com.

[Martin Kouba]

Hi Bill,

that's a very good question. From my point of view, it's not a bad
pattern per se. But it's more about whether you want to notify the
observers synchronously, blocking the current thread, or asynchronously,
offloaded to another thread. In many cases, you probably only need one
or the other.

For example, we fire the HttpServerStart [1] event asynchronously,
because we don't want to block the HTTP server from starting. On the
other hand, the StartupEvent [2] is fired synchronously because we want
to block the start of the application until all startup logic is finished.

HTH

Martin

[1]
https://github.com/quarkusio/quarkus/blob/main/extensions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/HttpServerStart.java

[2]
https://github.com/quarkusio/quarkus/blob/main/core/runtime/src/main/java/io/quarkus/runtime/StartupEvent.java

On 5/29/26 15:29, 'William Burke' via Quarkus Development mailing list
wrote:

> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-
> dev+uns...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/quarkus-
> dev/
> CAL%3DE%3DjRoDB1f13SydXUHViUzYeRcctkiS4upmWaVMttgFx5pjA%40mail.gmail.com

> <https://groups.google.com/d/msgid/quarkus-dev/
> CAL%3DE%3DjRoDB1f13SydXUHViUzYeRcctkiS4upmWaVMttgFx5pjA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Eric Deandrea]

Eric Deandrea

Java Champion

Senior Principal Software Engineer

Quarkus | LangChain4j | Docling-Java

Red Hat

edea...@redhat.com    M: 603.453.5840

On May 29, 2026 at 9:49:43 AM, 'Martin Kouba' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

Hi Bill,

that's a very good question. From my point of view, it's not a bad
pattern per se. But it's more about whether you want to notify the
observers synchronously, blocking the current thread, or asynchronously,
offloaded to another thread. In many cases, you probably only need one
or the other.

For example, we fire the HttpServerStart [1] event asynchronously,
because we don't want to block the HTTP server from starting. On the
other hand, the StartupEvent [2] is fired synchronously because we want

to block the start of the application until all startup logic is finished.'

Would a “proper” approach be to fire synchronously, and if the consumer doesn’t want to block, they can manage the threading themselves?

There just may be plenty of times where the producer is firing an event and it doesn’t necessarily know (or care) how the consumer wants to process it. Shouldn’t there be a way where the consumer dictates how the processing of the event is done? Without that, the producer is somewhat coupled to its consumers (both sides have to know whether an event is sync or async).

To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/872ea557-4bcd-4d9f-b2a7-954ed2d860fa%40redhat.com.

[Chris Cranford]

Hi Eric, I would argue its not always about how the consumer wants to receive the event, but also the context in which the producer emits the event. If a producer bean observes an event that itself raises from within a @PostConstruct handler, you're forced to use asynchronous to avoid StackOverflow (observer recreates a new bean because the PostConstruct on the bean isn't yet done), or create two independent beans to handle a single concern.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAOTfCRWWueCNnTfoch6rB-dJh0-q6FjaeuCN8nT-nEK%2BzuuO0A%40mail.gmail.com.

--

Chris Cranford

Principal Software Engineer

APIs, Events, & Integration - Debezium

ccra...@redhat.com   

Red Hat

[Georgios Andrianakis]

From my PoV, taking the producers view is the appropriate framing 

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/601ccb89-04a6-4499-985d-07415c75490d%40redhat.com.

[Martin Kouba]

On 5/29/26 15:53, 'Eric Deandrea' via Quarkus Development mailing list
wrote:
>
>

> Eric Deandrea
>
> Java Champion
>
> Senior Principal Software Engineer
>
> Quarkus | LangChain4j | Docling-Java
>

> Red Hat <https://www.redhat.com/>
>
> edea...@redhat.com <mailto:edea...@redhat.com> M: 603.453.5840
>
> <https://red.ht/sig>

>
>
>
>
> On May 29, 2026 at 9:49:43 AM, 'Martin Kouba' via Quarkus Development

> mailing list <quark...@googlegroups.com <mailto:quarkus-

> d...@googlegroups.com>> wrote:
>> Hi Bill,
>>
>> that's a very good question. From my point of view, it's not a bad
>> pattern per se. But it's more about whether you want to notify the
>> observers synchronously, blocking the current thread, or asynchronously,
>> offloaded to another thread. In many cases, you probably only need one
>> or the other.
>>
>> For example, we fire the HttpServerStart [1] event asynchronously,
>> because we don't want to block the HTTP server from starting. On the
>> other hand, the StartupEvent [2] is fired synchronously because we want
>> to block the start of the application until all startup logic is
>> finished.'
>
> Would a “proper” approach be to fire synchronously, and if the consumer
> doesn’t want to block, they can manage the threading themselves?

That's very inconvenient if you ask me, and obviously most consumers do
not care about the producers either.

>
> There just may be plenty of times where the producer is firing an event
> and it doesn’t necessarily know (or care) how the consumer wants to
> process it.

If it does not care then it should be async, because otherwise consumers
affect the producers significantly.

> Shouldn’t there be a way where the consumer dictates how the
> processing of the event is done? Without that, the producer is somewhat
> coupled to its consumers (both sides have to know whether an event is
> sync or async).
>
>>
>> HTH
>>
>> Martin
>>
>> [1]
>> https://github.com/quarkusio/quarkus/blob/main/extensions/vertx-http/
>> runtime/src/main/java/io/quarkus/vertx/http/HttpServerStart.java

>> <https://github.com/quarkusio/quarkus/blob/main/extensions/vertx-http/
>> runtime/src/main/java/io/quarkus/vertx/http/HttpServerStart.java>
>>
>> [2]
>> https://github.com/quarkusio/quarkus/blob/main/core/runtime/src/main/
>> java/io/quarkus/runtime/StartupEvent.java <https://github.com/
>> quarkusio/quarkus/blob/main/core/runtime/src/main/java/io/quarkus/
>> runtime/StartupEvent.java>

>>
>> On 5/29/26 15:29, 'William Burke' via Quarkus Development mailing list
>> wrote:
>>>
>>> I'm assuming this behavior for firing events:
>>>
>>> * If you do event.fire() only subscribers that @Observes are called
>>> * If you do event.fireAsync() only subscribers that @ObservicesAsync are
>>> called
>>>
>>>
>>> Is it a bad pattern to do both event.fire() and event.fireAsync()?  That
>>> way subscribers that want the event synchronously can do their thing and
>>> subscribers that want it asynchronously do their thing?
>>>
>>> --
>>> Bill Burke
>>> IBM
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Quarkus Development mailing list" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-

>>> dev%2Bunsu...@googlegroups.com> <mailto:quarkus- <mailto:quarkus->
>>> dev+uns...@googlegroups.com
>>> <mailto:dev%2Bunsu...@googlegroups.com>>.

>>> To view this discussion visit https://groups.google.com/d/msgid/

>>> quarkus- <https://groups.google.com/d/msgid/quarkus->
>>> dev/
>>> CAL%3DE%3DjRoDB1f13SydXUHViUzYeRcctkiS4upmWaVMttgFx5pjA%40mail.gmail.com <http://40mail.gmail.com>
>>> <https://groups.google.com/d/msgid/quarkus-dev/ <https://
>>> groups.google.com/d/msgid/quarkus-dev/>
>>> CAL%3DE%3DjRoDB1f13SydXUHViUzYeRcctkiS4upmWaVMttgFx5pjA%40mail.gmail.com?utm_medium=email&utm_source=footer <http://40mail.gmail.com?utm_medium=email&utm_source=footer>>.

>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Quarkus Development mailing list" group.
>> To unsubscribe from this group and stop receiving emails from it, send

>> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-
>> dev%2Bunsu...@googlegroups.com>.

>> To view this discussion visit https://groups.google.com/d/msgid/

>> quarkus-dev/872ea557-4bcd-4d9f-b2a7-954ed2d860fa%40redhat.com
>> <https://groups.google.com/d/msgid/quarkus-dev/872ea557-4bcd-4d9f-
>> b2a7-954ed2d860fa%40redhat.com>.

>>
> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/quarkus-

> dev/CAOTfCRWWueCNnTfoch6rB-dJh0-q6FjaeuCN8nT-
> nEK%2BzuuO0A%40mail.gmail.com <https://groups.google.com/d/msgid/
> quarkus-dev/CAOTfCRWWueCNnTfoch6rB-dJh0-q6FjaeuCN8nT-
> nEK%2BzuuO0A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Matej Novotny]

I wouldn't say it is necessarily a bad pattern but it is uncommon.

Most of the time, it is just like Martin says - you pick one or the other based on whether you want/expect it to be blocking.

That said, I do recall us firing both somewhere - StatusEmitterInvoker in scheduler extension I think?

But since you are talking CDI spec events, the most important part is to properly document that you fire sync or async event at certain point in time so users know how to observe them.

> Would a “proper” approach be to fire synchronously, and if the consumer doesn’t want to block, they can manage the threading themselves?

Unfortunately, as far as CDI goes, we have our hands bound unless we decide to break the whole eventing system :)

The new Signals extension would offer the flexibility you are talking about.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/601ccb89-04a6-4499-985d-07415c75490d%40redhat.com.

[Martin Kouba]

On 5/29/26 16:26, 'Matej Novotny' via Quarkus Development mailing list
wrote:

> I wouldn't say it is necessarily a bad pattern but it is uncommon.
> Most of the time, it is just like Martin says - you pick one or the
> other based on whether you want/expect it to be blocking.
> That said, I do recall us firing both somewhere - StatusEmitterInvoker
> in scheduler extension I think?
> But since you are talking CDI spec events, the most important part is to
> properly document that you fire sync or async event at certain point in
> time so users know how to observe them.
>
> > Would a “proper” approach be to fire synchronously, and if the
> consumer doesn’t want to block, they can manage the threading themselves?
>
> Unfortunately, as far as CDI goes, we have our hands bound unless we
> decide to break the whole eventing system :)
> The new Signals extension would offer the flexibility you are talking about.

Yes, because in Signals, all receivers are always notified
asynchronously. So it never blocks the signal emitter unless explicitly
required.

>
> On Fri, May 29, 2026 at 4:02 PM 'Chris Cranford' via Quarkus Development

> mailing list <quark...@googlegroups.com <mailto:quarkus-
> d...@googlegroups.com>> wrote:
>
> __

> Hi Eric, I would argue its not always about how the consumer wants
> to receive the event, but also the context in which the producer
> emits the event. If a producer bean observes an event that itself
> raises from within a @PostConstruct handler, you're forced to use
> asynchronous to avoid StackOverflow (observer recreates a new bean
> because the PostConstruct on the bean isn't yet done), or create two
> independent beans to handle a single concern.
>
> On 5/29/26 9:53 AM, 'Eric Deandrea' via Quarkus Development mailing
> list wrote:
>>
>>
>> Eric Deandrea
>>
>> Java Champion
>>
>> Senior Principal Software Engineer
>>
>> Quarkus | LangChain4j | Docling-Java
>>

>> Red Hat <https://www.redhat.com/>
>>
>> edea...@redhat.com <mailto:edea...@redhat.com> M: 603.453.5840
>>
>> <https://red.ht/sig>
>>
>>
>>
>>

>> On May 29, 2026 at 9:49:43 AM, 'Martin Kouba' via Quarkus
>> Development mailing list <quark...@googlegroups.com

>>> HttpServerStart.java <https://github.com/quarkusio/quarkus/blob/
>>> main/extensions/vertx-http/runtime/src/main/java/io/quarkus/

>>> vertx/http/HttpServerStart.java>
>>>
>>> [2]
>>> https://github.com/quarkusio/quarkus/blob/main/core/runtime/src/
>>> main/java/io/quarkus/runtime/StartupEvent.java <https://
>>> github.com/quarkusio/quarkus/blob/main/core/runtime/src/main/
>>> java/io/quarkus/runtime/StartupEvent.java>
>>>

>>> On 5/29/26 15:29, 'William Burke' via Quarkus Development mailing
>>> list
>>> wrote:
>>>>
>>>> I'm assuming this behavior for firing events:
>>>>
>>>> * If you do event.fire() only subscribers that @Observes are called
>>>> * If you do event.fireAsync() only subscribers
>>>> that @ObservicesAsync are
>>>> called
>>>>
>>>>
>>>> Is it a bad pattern to do both event.fire() and
>>>> event.fireAsync()?  That
>>>> way subscribers that want the event synchronously can do their
>>>> thing and
>>>> subscribers that want it asynchronously do their thing?
>>>>
>>>> --
>>>> Bill Burke
>>>> IBM
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Quarkus Development mailing list" group.
>>>> To unsubscribe from this group and stop receiving emails from
>>>> it, send
>>>> an email to quarkus-dev...@googlegroups.com

>>>> <mailto:quarkus-dev%2Bunsu...@googlegroups.com>

>>>> <mailto:quarkus- <mailto:quarkus->
>>>> dev+uns...@googlegroups.com
>>>> <mailto:dev%2Bunsu...@googlegroups.com>>.
>>>> To view this discussion visit https://groups.google.com/d/msgid/
>>>> quarkus- <https://groups.google.com/d/msgid/quarkus->
>>>> dev/
>>>> CAL%3DE%3DjRoDB1f13SydXUHViUzYeRcctkiS4upmWaVMttgFx5pjA%40mail.gmail.com <http://40mail.gmail.com>
>>>> <https://groups.google.com/d/msgid/quarkus-dev/ <https://
>>>> groups.google.com/d/msgid/quarkus-dev/>

>>>> CAL%3DE%3DjRoDB1f13SydXUHViUzYeRcctkiS4upmWaVMttgFx5pjA%40mail.gmail.com?utm_medium=email&utm_source=footer <http://40mail.gmail.com?utm_medium=email&utm_source=footer>>.

>>>
>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "Quarkus Development mailing list" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to quarkus-dev...@googlegroups.com

>>> <mailto:quarkus-dev%2Bunsu...@googlegroups.com>.

>>> To view this discussion visit https://groups.google.com/d/msgid/
>>> quarkus-dev/872ea557-4bcd-4d9f-b2a7-954ed2d860fa%40redhat.com
>>> <https://groups.google.com/d/msgid/quarkus-

>>> dev/872ea557-4bcd-4d9f-b2a7-954ed2d860fa%40redhat.com>.

>>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Quarkus Development mailing list" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to quarkus-dev...@googlegroups.com

>> <mailto:quarkus-dev...@googlegroups.com>.

>> To view this discussion visit https://groups.google.com/d/msgid/
>> quarkus-dev/CAOTfCRWWueCNnTfoch6rB-dJh0-q6FjaeuCN8nT-
>> nEK%2BzuuO0A%40mail.gmail.com <https://groups.google.com/d/msgid/
>> quarkus-dev/CAOTfCRWWueCNnTfoch6rB-dJh0-q6FjaeuCN8nT-
>> nEK%2BzuuO0A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>

> --
>
> Chris Cranford
>
> Principal Software Engineer
>
> APIs, Events, & Integration - Debezium
>

> ccra...@redhat.com <mailto:ccra...@redhat.com>
>
> Red Hat <https://www.redhat.com>
>
> <https://www.redhat.com>

>
> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to quarkus-dev...@googlegroups.com

> <mailto:quarkus-dev...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> quarkus-dev/601ccb89-04a6-4499-985d-07415c75490d%40redhat.com
> <https://groups.google.com/d/msgid/quarkus-
> dev/601ccb89-04a6-4499-985d-07415c75490d%40redhat.com?

> utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/quarkus-
> dev/

> CAK6NyhAkt7iGTz5thbak98oK%2B4cHxUOBuSFzN89iJF_GmLue9g%40mail.gmail.com
> <https://groups.google.com/d/msgid/quarkus-dev/
> CAK6NyhAkt7iGTz5thbak98oK%2B4cHxUOBuSFzN89iJF_GmLue9g%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Eric Deandrea]

Bill and I are just trying to think of the best solution for our use case.

In some instances, the flow should be synchronous, but in others it should be async. So maybe the better approach is just fire sync and the consumer can do the threading themselves if they want async.

Not that it matters, but in Spring this is not an issue. The producer just fires the event. It’s up to each consumer to decide whether they want to receive it sync or async. You can even have multiple consumers of the event that handle it differently.

The publishing of the event itself always happens on the same thread as the code producing the event, but then the threading delegation is handled just before the event is delivered to the consumer.

Eric Deandrea

Java Champion

Senior Principal Software Engineer

Quarkus | LangChain4j | Docling-Java

Red Hat

edea...@redhat.com    M: 603.453.5840

To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/da4a3eb9-c777-4a1c-b70d-cf8a09ebc677%40redhat.com.

[Martin Kouba]

On 5/29/26 17:00, 'Eric Deandrea' via Quarkus Development mailing list
wrote:

> Bill and I are just trying to think of the best solution for our use case.
>
> In some instances, the flow should be synchronous, but in others it
> should be async. So maybe the better approach is just fire sync and the
> consumer can do the threading themselves if they want async.

But if the flow should be async then you can't leave it to the
consumers. That does not make sense.

>
> Not that it matters, but in Spring this is not an issue. The producer
> just fires the event. It’s up to each consumer to decide whether they
> want to receive it sync or async. You can even have multiple consumers
> of the event that handle it differently.

One of the consequence is that for sync notifications you don't need to
care about concurrent access for mutable payload. If you have immutable
payload (best practice IMO) then you don't care obviously.

>
> The publishing of the event itself always happens on the same thread as
> the code producing the event, but then the threading delegation is
> handled just before the event is delivered to the consumer.>
>
> Eric Deandrea
>
> Java Champion
>
> Senior Principal Software Engineer
>
> Quarkus | LangChain4j | Docling-Java
>

> Red Hat <https://www.redhat.com/>
>
> edea...@redhat.com <mailto:edea...@redhat.com> M: 603.453.5840
>
> <https://red.ht/sig>
>
>
>
>

> On May 29, 2026 at 10:50:08 AM, 'Martin Kouba' via Quarkus Development

> mailing list <quark...@googlegroups.com <mailto:quarkus-

> d...@googlegroups.com>> wrote:
>>
>>
>> On 5/29/26 16:26, 'Matej Novotny' via Quarkus Development mailing list
>> wrote:
>>> I wouldn't say it is necessarily a bad pattern but it is uncommon.
>>> Most of the time, it is just like Martin says - you pick one or the
>>> other based on whether you want/expect it to be blocking.
>>> That said, I do recall us firing both somewhere - StatusEmitterInvoker
>>> in scheduler extension I think?
>>> But since you are talking CDI spec events, the most important part is to
>>> properly document that you fire sync or async event at certain point in
>>> time so users know how to observe them.
>>>
>>>  > Would a “proper” approach be to fire synchronously, and if the
>>> consumer doesn’t want to block, they can manage the threading themselves?
>>>
>>> Unfortunately, as far as CDI goes, we have our hands bound unless we
>>> decide to break the whole eventing system :)
>>> The new Signals extension would offer the flexibility you are talking
>>> about.
>>
>> Yes, because in Signals, all receivers are always notified
>> asynchronously. So it never blocks the signal emitter unless explicitly
>> required.
>>
>>>
>>> On Fri, May 29, 2026 at 4:02 PM 'Chris Cranford' via Quarkus Development
>>> mailing list <quark...@googlegroups.com <mailto:quarkus-

>>> d...@googlegroups.com> <mailto:quarkus- <mailto:quarkus->

>>> d...@googlegroups.com <mailto:d...@googlegroups.com>>> wrote:
>>>
>>>     __
>>>     Hi Eric, I would argue its not always about how the consumer wants
>>>     to receive the event, but also the context in which the producer
>>>     emits the event. If a producer bean observes an event that itself
>>>     raises from within a @PostConstruct handler, you're forced to use
>>>     asynchronous to avoid StackOverflow (observer recreates a new bean
>>>     because the PostConstruct on the bean isn't yet done), or create two
>>>     independent beans to handle a single concern.
>>>
>>>     On 5/29/26 9:53 AM, 'Eric Deandrea' via Quarkus Development mailing
>>>     list wrote:
>>> >
>>> >
>>> >     Eric Deandrea
>>> >
>>> >     Java Champion
>>> >
>>> >     Senior Principal Software Engineer
>>> >
>>> >     Quarkus | LangChain4j | Docling-Java
>>> >

>>> >     Red Hat <https://www.redhat.com/ <https://www.redhat.com/>>
>>> >
>>> > edea...@redhat.com <mailto:edea...@redhat.com>
>>> <mailto:edea...@redhat.com <mailto:edea...@redhat.com>>
>>> M: 603.453.5840
>>> >
>>> >     <https://red.ht/sig <https://red.ht/sig>>

>>> >
>>> >
>>> >
>>> >
>>> >     On May 29, 2026 at 9:49:43 AM, 'Martin Kouba' via Quarkus
>>> >     Development mailing list <quark...@googlegroups.com
>>> <mailto:quark...@googlegroups.com>

>>> >     <mailto:quark...@googlegroups.com <mailto:quarkus-

>>> blob/ <https://github.com/quarkusio/quarkus/blob/>

>>> >>     main/extensions/vertx-http/runtime/src/main/java/io/quarkus/
>>> >>     vertx/http/HttpServerStart.java>
>>> >>
>>> >>     [2]
>>> >> https://github.com/quarkusio/quarkus/blob/main/core/runtime/src/
>>> <https://github.com/quarkusio/quarkus/blob/main/core/runtime/src/>
>>> >>     main/java/io/quarkus/runtime/StartupEvent.java <https://
>>> >> github.com/quarkusio/quarkus/blob/main/core/runtime/src/main/

>>> <http://github.com/quarkusio/quarkus/blob/main/core/runtime/src/main/>

>>> >>>     <mailto:quarkus-dev%2Bunsu...@googlegroups.com
>>> <mailto:quarkus-dev%252Buns...@googlegroups.com>>
>>> >>>     <mailto:quarkus- <mailto:quarkus-> <mailto:quarkus-

>>> <mailto:quarkus->>
>>> >>> dev+uns...@googlegroups.com
>>> <mailto:dev%2Bunsu...@googlegroups.com>

>>> >>>     <mailto:dev%2Bunsu...@googlegroups.com
>>> <mailto:dev%252Buns...@googlegroups.com>>>.

>>> >>>     To view this discussion visit https://groups.google.com/d/

>>> msgid/ <https://groups.google.com/d/msgid/>

>>> >>>     quarkus- <https://groups.google.com/d/msgid/quarkus-
>>> <https://groups.google.com/d/msgid/quarkus->>
>>> >>>     dev/
>>> >>>

>>>     CAL%3DE%3DjRoDB1f13SydXUHViUzYeRcctkiS4upmWaVMttgFx5pjA%40mail.gmail.com <http://40mail.gmail.com> <http://40mail.gmail.com <http://40mail.gmail.com>>
>>> >>>     <https://groups.google.com/d/msgid/quarkus-dev/ <https://
>>> groups.google.com/d/msgid/quarkus-dev/> <https://
>>> >>> groups.google.com/d/msgid/quarkus-dev/ <http://groups.google.com/
>>> d/msgid/quarkus-dev/>>
>>> >>>
>>>     CAL%3DE%3DjRoDB1f13SydXUHViUzYeRcctkiS4upmWaVMttgFx5pjA%40mail.gmail.com?utm_medium=email&utm_source=footer <http://40mail.gmail.com?utm_medium=email&utm_source=footer> <http://40mail.gmail.com?utm_medium=email&utm_source=footer <http://40mail.gmail.com?utm_medium=email&utm_source=footer>>>.

>>> >>
>>> >>     --
>>> >>     You received this message because you are subscribed to the
>>> >>     Google Groups "Quarkus Development mailing list" group.
>>> >>     To unsubscribe from this group and stop receiving emails from it,
>>> >>     send an email to quarkus-dev...@googlegroups.com
>>> <mailto:quarkus-dev%2Bunsu...@googlegroups.com>

>>> >>     <mailto:quarkus-dev%2Bunsu...@googlegroups.com
>>> <mailto:quarkus-dev%252Buns...@googlegroups.com>>.

>>> >>     To view this discussion visit https://groups.google.com/d/

>>> msgid/ <https://groups.google.com/d/msgid/>
>>> >>     quarkus-dev/872ea557-4bcd-4d9f-b2a7-954ed2d860fa%40redhat.com
>>> <http://40redhat.com>
>>> >>     <https://groups.google.com/d/msgid/quarkus- <https://
>>> groups.google.com/d/msgid/quarkus->
>>> >>     dev/872ea557-4bcd-4d9f-b2a7-954ed2d860fa%40redhat.com
>>> <http://40redhat.com>>.

>>> >>
>>> >     --
>>> >     You received this message because you are subscribed to the Google
>>> >     Groups "Quarkus Development mailing list" group.
>>> >     To unsubscribe from this group and stop receiving emails from it,
>>> >     send an email to quarkus-dev...@googlegroups.com
>>> <mailto:quarkus-dev%2Bunsu...@googlegroups.com>

>>> >     <mailto:quarkus-dev...@googlegroups.com

>>> <mailto:quarkus-dev%2Bunsu...@googlegroups.com>>.
>>> >     To view this discussion visit https://groups.google.com/d/

>>> msgid/ <https://groups.google.com/d/msgid/>
>>> >     quarkus-dev/CAOTfCRWWueCNnTfoch6rB-dJh0-q6FjaeuCN8nT-
>>> >     nEK%2BzuuO0A%40mail.gmail.com <http://40mail.gmail.com>
>>> <https://groups.google.com/d/msgid/ <https://groups.google.com/d/msgid/>
>>> >     quarkus-dev/CAOTfCRWWueCNnTfoch6rB-dJh0-q6FjaeuCN8nT-
>>> >     nEK%2BzuuO0A%40mail.gmail.com?
>>> utm_medium=email&utm_source=footer <http://40mail.gmail.com?

>>> utm_medium=email&utm_source=footer>>.
>>>
>>>     --
>>>
>>>     Chris Cranford
>>>
>>>     Principal Software Engineer
>>>
>>>     APIs, Events, & Integration - Debezium
>>>
>>> ccra...@redhat.com <mailto:ccra...@redhat.com>

>>> <mailto:ccra...@redhat.com <mailto:ccra...@redhat.com>>

>>>
>>>     Red Hat <https://www.redhat.com <https://www.redhat.com>>
>>>
>>>     <https://www.redhat.com <https://www.redhat.com>>
>>>
>>>     --
>>>     You received this message because you are subscribed to the Google
>>>     Groups "Quarkus Development mailing list" group.
>>>     To unsubscribe from this group and stop receiving emails from it,
>>>     send an email to quarkus-dev...@googlegroups.com

>>> <mailto:quarkus-dev%2Bunsu...@googlegroups.com>
>>>     <mailto:quarkus-dev...@googlegroups.com <mailto:quarkus-

>>> dev%2Bunsu...@googlegroups.com>>.
>>>     To view this discussion visit https://groups.google.com/d/msgid/

>>> <https://groups.google.com/d/msgid/>
>>>     quarkus-dev/601ccb89-04a6-4499-985d-07415c75490d%40redhat.com
>>> <http://40redhat.com>
>>>     <https://groups.google.com/d/msgid/quarkus- <https://
>>> groups.google.com/d/msgid/quarkus->
>>>     dev/601ccb89-04a6-4499-985d-07415c75490d%40redhat.com
>>> <http://40redhat.com>?

>>>     utm_medium=email&utm_source=footer>.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Quarkus Development mailing list" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-

>>> dev%2Bunsu...@googlegroups.com> <mailto:quarkus- <mailto:quarkus->
>>> dev+uns...@googlegroups.com
>>> <mailto:dev%2Bunsu...@googlegroups.com>>.
>>> To view this discussion visit https://groups.google.com/d/msgid/
>>> quarkus- <https://groups.google.com/d/msgid/quarkus->
>>> dev/

>>> CAK6NyhAkt7iGTz5thbak98oK%2B4cHxUOBuSFzN89iJF_GmLue9g%40mail.gmail.com <http://40mail.gmail.com>

>>> <https://groups.google.com/d/msgid/quarkus-dev/ <https://
>>> groups.google.com/d/msgid/quarkus-dev/>

>>> CAK6NyhAkt7iGTz5thbak98oK%2B4cHxUOBuSFzN89iJF_GmLue9g%40mail.gmail.com <http://40mail.gmail.com>?

>>> utm_medium=email&utm_source=footer>.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Quarkus Development mailing list" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-

>> dev%2Bunsu...@googlegroups.com>.
>> To view this discussion visit https://groups.google.com/d/msgid/

>> quarkus-dev/da4a3eb9-c777-4a1c-b70d-cf8a09ebc677%40redhat.com
>> <https://groups.google.com/d/msgid/quarkus-dev/da4a3eb9-c777-4a1c-
>> b70d-cf8a09ebc677%40redhat.com>.

>>
> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/quarkus-

> dev/CAOTfCRUAemUOYQ3YNF3d3JnmwV7RMscsBiAJ1_Q7hVomO_cnKQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/quarkus-dev/
> CAOTfCRUAemUOYQ3YNF3d3JnmwV7RMscsBiAJ1_Q7hVomO_cnKQ%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Eric Deandrea]

Eric Deandrea

Java Champion

Senior Principal Software Engineer

Quarkus | LangChain4j | Docling-Java

Red Hat

edea...@redhat.com    M: 603.453.5840

On May 29, 2026 at 12:37:50 PM, 'Martin Kouba' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

On 5/29/26 17:00, 'Eric Deandrea' via Quarkus Development mailing list
wrote:

Bill and I are just trying to think of the best solution for our use case.

In some instances, the flow should be synchronous, but in others it

should be async. So maybe the better approach is just fire sync and the

consumer can do the threading themselves if they want async.

But if the flow should be async then you can't leave it to the
consumers. That does not make sense.

In our case the consumer drives the flow, not the producer. Some consumers need it sync. Others need it async. It shouldn’t be up to the producer to decide.

Not that it matters, but in Spring this is not an issue. The producer

just fires the event. It’s up to each consumer to decide whether they

want to receive it sync or async. You can even have multiple consumers

of the event that handle it differently.

One of the consequence is that for sync notifications you don't need to
care about concurrent access for mutable payload. If you have immutable
payload (best practice IMO) then you don't care obviously.

And yes event payloads should always be immutable.

To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/c47c95b0-d8a8-4989-98d8-def4af117ab6%40redhat.com.