Upgrade to Quarkus 2.8

[sophokles73]

fixes #3219

[calohmn]

It seems the failing test testScenarioWithPartitionRevokedWhileHandlingIncomplete() in AsyncHandlingAutoCommitKafkaConsumerTest will be fixed with the changes made in #3223 (adding consumer.addOnKafkaConsumerReadyHandler(readyTracker); and waiting on the readyTracker).

[sophokles73]

@calohmn so you are suggesting to merge this PR once #3223 has been merged, right?

[calohmn]

@sophokles73 yes

[calohmn]

The DropHttpRequestSpansSampler class needs to be adapted here.
In the shouldSample method, the .substring(1) part needs to be removed, along with the comment in the line above.
See quarkusio/quarkus#24017 (comment).

[sophokles73]

Ok, I will apply that change

[sophokles73]

It seems the failing test testScenarioWithPartitionRevokedWhileHandlingIncomplete() in AsyncHandlingAutoCommitKafkaConsumerTest will be fixed with the changes made in #3223

@calohmn doesn't seem to be the case. Any idea why the checkpoint is being flagged more than once?

[calohmn]

doesn't seem to be the case. Any idea why the checkpoint is being flagged more than once?

@sophokles73 It seems to me like a general issue with the test. I'm looking into a fix. I don't currently see how this is related with the Quarkus update.

[sophokles73]

I don't currently see how this is related with the Quarkus update.

neither do I

[calohmn]

The issue with the testScenarioWithPartitionRevokedWhileHandlingIncomplete test seems to be, that the OnPartitionsAssignedHandler declared at the bottom of the test is not only run on the last rebalance, but sometimes also already on the rebalance before that.

Replacing mockConsumer.rebalance(List.of(TOPIC2_PARTITION)); in line 793 with

        final CountDownLatch rebalanceWithTopic2Done = new CountDownLatch(1);
        consumer.setOnPartitionsAssignedHandler(partitions -> {
            rebalanceWithTopic2Done.countDown();
        });
        mockConsumer.rebalance(List.of(TOPIC2_PARTITION));
        rebalanceWithTopic2Done.await();

should fix the issue, making sure that the bottom OnPartitionsAssignedHandler is only run after the last rebalance, as intended by the test.

[sophokles73]

ok, I will give it a shot

[calohmn]

The failing test is actually due to the newer Vert.x version being used here.
The Strict checkpoint flagged too many times check has only been introduced in Vert.x 4.2.6 (see eclipse-vertx/vertx-junit5#113).

[calohmn]

LGTM
Follow-up commits/PRs could then address re-enabling of parallel unit-test execution and removal of added vert.x traces for event bus messages (they are not useful IMHO).

[sophokles73]

removal of added vert.x traces for event bus messages (they are not useful IMHO).

@calohmn can you point me to the corresponding code?

[calohmn]

@calohmn can you point me to the corresponding code?

It's about traces created by means of the Quarkus EventBusInstrumenterVertxTracer (e.g. notification.tenant-change-v1 send or authentication.in send).
Since usage of this instrumenter isn't configurable, it seems the only way to drop these traces is in a way similar to the DropHttpRequestSpansSampler.
I'm already looking into creating a PR for this.

[sophokles73]

ok, I am working on a PR for re-enabling parallel test execution ...