You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
while upgrading our Quarkus services from 1.10.4 to 1.11.3 we noticed that the behaviour of the Vert.x event bus significally changed. The event bus does not utilize more than one thread from the worker thread pool and the execution of multiple events is therefore not concurrent as it was prior to 1.11.X.
I could not find any hints in the changelogs or the migration guide why the behaviour changed.
If this new behaviour is indeed expectec, how can we handle the conccurrent execution of events if we do not want to use reactive style code?
Expected behavior
ConsumeEvent with blocking=true should utilize all available worker pool threads and execute events concrrently.
Actual behavior
The execution of events seems to only use a single worker thread and does not execute events concurrently.
Example Code
Bean with some long running job:
@Dependent
public class SomeJobClass {
private static final Logger LOG = Logger.getLogger(SomeJobClass.class);
public void longRunningJob(String test) {
LOG.info("Executing");
try {
Thread.sleep(1000l);
} catch (InterruptedException e) {
e.printStackTrace();
}
LOG.info("finished");
}
}
- Add an `ordered` attribute to the `@ConsumeEvent` annotation (false by default, which was the previous behavior)
- When calling `executeBlocking`, configure whether the calls should be ordered or not
- Add an `ordered` attribute to the `@ConsumeEvent` annotation (false by default, which was the previous behavior)
- When calling `executeBlocking`, configure whether the calls should be ordered or not
Description
Greetings,
while upgrading our Quarkus services from 1.10.4 to 1.11.3 we noticed that the behaviour of the Vert.x event bus significally changed. The event bus does not utilize more than one thread from the worker thread pool and the execution of multiple events is therefore not concurrent as it was prior to 1.11.X.
I could not find any hints in the changelogs or the migration guide why the behaviour changed.
If this new behaviour is indeed expectec, how can we handle the conccurrent execution of events if we do not want to use reactive style code?
Expected behavior
ConsumeEvent with
blocking=true
should utilize all available worker pool threads and execute events concrrently.Actual behavior
The execution of events seems to only use a single worker thread and does not execute events concurrently.
Example Code
Bean with some long running job:
The class containing the consumer:
Send 2 events:
Log output with Quarkus 1.11.2.FINAL:
Log output with Quarkus 1.10.5.FINAL:
The logs show that the execution with version 1.11.2.FINAL was not concurrent and is using only
vert.x-worker-thread-0
.The text was updated successfully, but these errors were encountered: