Repair Quarkus Vert.x benchmark

[tsegismont]

Follows-up on #10715

The Ongres SCRAM dependency is required for authentication with the database.

[github-actions]

The following frameworks were updated, pinging maintainers:
quarkus: @franz1981, @Sanne, @geoand

[joanhey]

Not only that, they need to calculate the length in each request !!!
#10715 (comment)

EDIT: or will be marked as stripped !!!

[joanhey]

Another big problem is the use of constant for the length header that is not permitted.

FrameworkBenchmarks/frameworks/Java/quarkus/vertx/src/main/java/io/quarkus/benchmark/resource/PlaintextHttpHandler.java

Line 15 in 33531b8

private static final CharSequence HELLO_WORLD_LENGTH = HttpHeaders.createOptimized("" + HELLO_WORLD.length());

FrameworkBenchmarks/frameworks/Java/quarkus/vertx/src/main/java/io/quarkus/benchmark/resource/PlaintextHttpHandler.java

Line 20 in 33531b8

headers.add(HttpHeaders.CONTENT_LENGTH, HELLO_WORLD_LENGTH);

[tsegismont]

@joanhey thanks for taking a look as well

Regarding your comments about the length header, I'm not a maintainer of this benchmark, consequently not in a position to discuss whether this should be changed.

The scope of this PR is repairing a broken benchmark, so not related to your issue anyway.

[joanhey]

Without the header change, this PR will not be merged.
Or It'll be marked as Stripped.

[tsegismont]

Except for plaintext in quarkus-reactive-routes-pgclient and quarkus-vertx, no Quarkus benchmark computes the content length beforehand.

My understanding is that this is compliant with the rule as explained in #10611 (comment)

@joanhey @msmith-techempower if I didn't get the statement wrong, can we get this PR merged after one of the maintainers has approved the PR?

[msmith-techempower]

@tsegismont I have to agree with @joanhey - we have been really pushing to be more equitable about the stripped implementations. Without the header changes or marking the implementation as 'Stripped', we won't merge. I recommend simply ensuring that the headers are computed on every request.

[tsegismont]

Thanks for your answer @msmith-techempower

tl;dr - plaintext is the "fun" one where frameworks can do whatever they want to try and go brrrrr, but the rest need to follow the rules or the framework will be marked "Stripped".

So, this is no longer true?

[joanhey]

If you want to play in the bench, you need to be a fair player !!
Thank you.

If you find another fw than make the same, please mark it as Stripped.

[tsegismont]

If you want to play in the bench, you need to be a fair player !! Thank you.

If this is a general statement, I fully agree.

If you find another fw than make the same, please mark it as Stripped.

Sorry I'm not comfortable with sending PRs to other participants marking their implementation as stripped. I don't believe this would cultivate a positive competitive spirit.

[msmith-techempower]

I looked at the Quarkus implementations and I think that it aligns with what I said in #10611 (comment) - only the Plaintext implementation uses the static length of the response body in the header. JSON, for instance, does not set the content length manually and leverages the framework to do that work.

That is the intent of the 'Realistic vs. Stripped' classification. If a developer would actually write the code for non-Plaintext test implementations as such, then that is a 'Realistic' approach. Plaintext is allowed to be non-realistic. We only mark the specific framework permutation as 'Stripped' if a) they only implement Plaintext (and this is disallowed moving forward) or b) the implementations are unrealistic (e.g., manually setting header values like content length to a static known amount etc.).