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

Cover Vert.X-specific metrics. #1019

Merged
merged 1 commit into from
Jan 31, 2023

Conversation

fedinskiy
Copy link
Contributor

Summary

Add new module, which uses Vert.X-based HTTP server Verify, that it works, and that it creates all required metrics Required for https://issues.redhat.com/browse/QUARKUS-2829

Please select the relevant options.

  • Bug fix (non-breaking change which fixes an issue)
  • Dependency update
  • Refactoring
  • Backport
  • New scenario (non-breaking change which adds functionality)
  • This change requires a documentation update
  • This change requires execution against OCP (use run tests phrase in comment)

Checklist:

  • Methods and classes used in PR scenarios are meaningful
  • Commits are well encapsulated and follow the best practices

@fedinskiy fedinskiy requested a review from pjgg January 27, 2023 13:09
@fedinskiy
Copy link
Contributor Author

run tests

Copy link
Contributor

@pjgg pjgg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Over all looks good, but I am not sure if the app would be more "Vertx" with Reactive routes rather than Resteasy.

https://quarkus.io/guides/reactive-routes

Reactive Routes are still supported, especially if you want a more route-based approach, and something closer to the underlying reactive engine. 

Map<String, Metric> metrics = parseMetrics(body);
assertTrue(metrics.containsKey("worker_pool_active"));
assertTrue(metrics.containsKey("worker_pool_completed_total"));
assertTrue(metrics.containsKey("worker_pool_queue_size"));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could also check the following metrics:
worker_pool_queue_delay_seconds_max
worker_pool_queue_delay_seconds_count
worker_pool_queue_delay_seconds_sum
worker_pool_usage_seconds_count
worker_pool_usage_seconds_sum
worker_pool_ratio
worker_pool_idle

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They all go together anyway, and we cannot even reliably check the content of these. I am not sure additional checks will play a role there.

@OpenShiftScenario
public class OpenShiftHttpMinimumIT extends AbstractIT {
@QuarkusApplication
static RestService app = new RestService();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that, you can move this RestService to "AbstractIT" and

  @Override
    public RequestSpecification requests() {
        return app.given();
    }

could be removed.

On AbstractIT just invoke restassurance.

for example:

public abstract class AbstractIT {

    @QuarkusApplication
    static RestService app = new RestService();
        given().get("/hello?name=you").then().statusCode(HttpStatus.SC_OK).body("content", is("Hello, you!"));

So, all platform classes should be empty in this case, because you don't have any particular configuration into any component.

Copy link
Contributor Author

@fedinskiy fedinskiy Jan 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to have all state in the endpoint classes and use the abstract one only as a source of common code.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok but I think this is common to all the scenarios

@QuarkusApplication
    static RestService app = new RestService();

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And this code Is not necessary:

@Override
    public RequestSpecification requests() {
        return app.given();
    }

so all commonCode would be in vertxCommonsIT (the abstract one)

@fedinskiy
Copy link
Contributor Author

@fedinskiy fedinskiy requested a review from pjgg January 27, 2023 15:08
@fedinskiy fedinskiy added the triage/backport-2.13? It needs to backport changes to branch 2.13 label Jan 27, 2023
@fedinskiy
Copy link
Contributor Author

run tests

@@ -0,0 +1,33 @@
package io.quarkus.ts.http.minimum;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is Http minimum the right package?

@pjgg pjgg self-requested a review January 30, 2023 08:34
@fedinskiy
Copy link
Contributor Author

run tests

Copy link
Contributor

@pjgg pjgg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, let's wait to CI

Copy link
Contributor

@pjgg pjgg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some errors on OCP native that should be reviewed

Add new module, which uses Vert.X-based HTTP server
Verify, that it works, and that it creates all required metrics
Required for https://issues.redhat.com/browse/QUARKUS-2829
@fedinskiy
Copy link
Contributor Author

run tests

@pjgg
Copy link
Contributor

pjgg commented Jan 31, 2023

Vertx OCP CI modules succeed: Quarkus QE TS: HTTP: Vert.X ........................ SUCCESS [11:26 min]

@pjgg pjgg self-requested a review January 31, 2023 08:08
@pjgg pjgg merged commit 818837f into quarkus-qe:main Jan 31, 2023
pjgg pushed a commit to pjgg/quarkus-test-suite that referenced this pull request Jan 31, 2023
Add new module, which uses Vert.X-based HTTP server
Verify, that it works, and that it creates all required metrics
Required for https://issues.redhat.com/browse/QUARKUS-2829

(cherry picked from commit 818837f)
pjgg pushed a commit to pjgg/quarkus-test-suite that referenced this pull request Jan 31, 2023
Add new module, which uses Vert.X-based HTTP server
Verify, that it works, and that it creates all required metrics
Required for https://issues.redhat.com/browse/QUARKUS-2829

(cherry picked from commit 818837f)
pjgg pushed a commit that referenced this pull request Feb 1, 2023
… modules (#1021)

* Test Extended Architecture (XA) connection

Provides coverage for https://issues.redhat.com/browse/QUARKUS-2742

(cherry picked from commit ce15b26)

* Improve reactive rest client "process paths before sub resources" scenario (#995)

There is an issue in upstream (quarkusio/quarkus#29821) that
only happens under some RestClient definition hierarchy.

This commit reproduces the problem in Quarkus 2.12 and earlier versions

(cherry picked from commit 2350b46)

* New Scenario: RequestScope custom context was removed after `javax.enterprise` event propagation

When firing an async CDI Event, the requestScope context from the emitter briefly exists for the observer
and is then terminated. This commit is a reproducer of this scenario that happens on Quarkus 2.13.0.Final

(cherry picked from commit ef3eed6)

* gRPC and SSE coverage for OpenTelemetry

(cherry picked from commit f327c60)

* Add coverage to eventbus '@ConsumeEvent' annotation

(cherry picked from commit 7da0d4b)

* Drop duplicated definition of quarkus-opentelemetry

(cherry picked from commit b0cba7f)

* OutboundSseEvent is not correctly serialized

(cherry picked from commit 99b5eb1)

* Check, that dev-mode is omitted on projects with pom packaging

Required for QUARKUS-2757

(cherry picked from commit 4fd38c7)

* Refactoring of QUARKUS-2748: adding http test and improving error messages

(cherry picked from commit 6563431)

* Add test for security annotations in rest-data-panache (#994)

Quarkus extensions based on `rest-data-panache` support propagation of
security annotations into generated JAX-RS resources.
These tests provide coverage of this feature for extensions:
- `quarkus-hibernate-orm-rest-data-panache`
- `quarkus-spring-data-rest`

See also related test plan:
- https://github.com/quarkus-qe/quarkus-test-plans/blob/main/QUARKUS-2788.md

(cherry picked from commit 3f7a4c8)

* Add transaction-API classic scenario

(cherry picked from commit 509d491)

* Cover Vert.X-specific metrics. (#1019)

Add new module, which uses Vert.X-based HTTP server
Verify, that it works, and that it creates all required metrics
Required for https://issues.redhat.com/browse/QUARKUS-2829

(cherry picked from commit 818837f)

* Add missing opentelemetry exporter to Narayana scenario

---------

Co-authored-by: Fedor Dudinskiy <[email protected]>
Co-authored-by: Rostislav Svoboda <[email protected]>
Co-authored-by: Josef Smrcka <[email protected]>
@pjgg pjgg added this to the 2.7 milestone Feb 2, 2023
@pjgg pjgg removed the triage/backport-2.13? It needs to backport changes to branch 2.13 label Feb 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants