Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocking @ConsumeEvent only uses single worker thread since 1.11.X #15351

Closed
kkosmrli opened this issue Feb 26, 2021 · 1 comment · Fixed by #15366
Closed

Blocking @ConsumeEvent only uses single worker thread since 1.11.X #15351

kkosmrli opened this issue Feb 26, 2021 · 1 comment · Fixed by #15366
Assignees
Labels
area/vertx kind/bug Something isn't working
Milestone

Comments

@kkosmrli
Copy link

kkosmrli commented Feb 26, 2021

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:

@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");
    }
}

The class containing the consumer:

@ApplicationScoped
public class ConsumerClass {

    @Inject
    SomeJobClass importer;

    @ConsumeEvent(value = "test", blocking = true)
    void test(String event) {
        importer.longRunningJob(event);
    }
}

Send 2 events:

@Test
@DisplayName("Some Test")
void testConcurrentEvents() throws InterruptedException {
    eventBus.send("test", "1");
    eventBus.send("test", "1");

    Thread.sleep(3000l);
    }

Log output with Quarkus 1.11.2.FINAL:

2021-02-26 13:53:29,994 INFO  [foo] (vert.x-worker-thread-0) Executing
2021-02-26 13:53:30,997 INFO  [foo] (vert.x-worker-thread-0) finished
2021-02-26 13:53:30,998 INFO  [foo] (vert.x-worker-thread-0) Executing
2021-02-26 13:53:32,002 INFO  [foo] (vert.x-worker-thread-0) finished

Log output with Quarkus 1.10.5.FINAL:

2021-02-26 14:02:19,345 INFO  [foo] (vert.x-worker-thread-0) Executing
2021-02-26 14:02:19,345 INFO  [foo] (vert.x-worker-thread-1) Executing
2021-02-26 14:02:20,349 INFO  [foo] (vert.x-worker-thread-0) finished
2021-02-26 14:02:20,349 INFO  [foo] (vert.x-worker-thread-1) finished

The logs show that the execution with version 1.11.2.FINAL was not concurrent and is using only vert.x-worker-thread-0.

@kkosmrli kkosmrli added the kind/bug Something isn't working label Feb 26, 2021
@cescoffier cescoffier self-assigned this Mar 1, 2021
@cescoffier cescoffier added this to the 1.13 - master milestone Mar 1, 2021
cescoffier added a commit to cescoffier/quarkus that referenced this issue Mar 1, 2021
- 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
@cescoffier
Copy link
Member

#15366 should fix it.

cescoffier added a commit to cescoffier/quarkus that referenced this issue Mar 1, 2021
- 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/vertx kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants