-
Notifications
You must be signed in to change notification settings - Fork 992
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
Improve JettyConnectionMetrics
connection type detection
#4325
Improve JettyConnectionMetrics
connection type detection
#4325
Conversation
The `HttpConnection` class was relocated to a different package in Jetty 12 which was causing a `NoClassDefFoundError` when doing an instanceof check on it. The goal of it is to determine whether the connection instrumented is a server connection or a client connection. However, it specifically checks against `HttpConnection` and assumes that all server connections will be an instanceof `HttpConnection` and any not an instanceof it are client connections. This is brittle because Jetty supports more implementations of `Connection` on the server side than `HttpConnection` and there could in theory be an arbitrary implementation where we do not know whether it is a server or client connection (it could also be neither). This instead checks whether the package name contains `server` or `client` or neither. This is admittedly also brittle, but given the known implementations of `Connection` provided by the Jetty project, this pattern generally seems to hold, and it is at least more honest using `UNKNOWN` when our heuristic fails. It also avoids the `NoClassDefFoundError` when using `JettyConnectionMetrics` with Jetty 12. Resolves micrometer-metricsgh-4324
@@ -2,11 +2,7 @@ description 'Micrometer instrumentation for Jetty 11' | |||
|
|||
dependencies { | |||
api project(":micrometer-core") | |||
api(libs.jetty11Server) { | |||
version { | |||
strictly libs.jetty11Server.get().version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was no longer needed since I removed the jetty dependencies from dependencies.gradle
in lieu of referring to the type-safe version catalog everywhere for jetty.
@@ -162,10 +161,16 @@ public void onClosed(Connection connection) { | |||
} | |||
|
|||
if (sample != null) { | |||
String serverOrClient = connection instanceof HttpConnection ? "server" : "client"; | |||
String type = "UNKNOWN"; | |||
if (connection.getClass().getName().contains("server")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to consider switching to make the qualified type name the value of the type
tag, but that would be breaking for anyone that relies on the current values. Hence I thought it better to consider that in a future version. This change should keep the prior values in most common cases, I hope.
The jdk11 build is failing because Jetty 12 requires Java 17. We could skip the jetty12 sample on jdk <17 or we could remove the jdk11 build. |
The
HttpConnection
class was relocated to a different package in Jetty 12 which was causing aNoClassDefFoundError
when doing an instanceof check on it. The goal of it is to determine whether the connection instrumented is a server connection or a client connection. However, it specifically checks againstHttpConnection
and assumes that all server connections will be an instanceofHttpConnection
and any not an instanceof it are client connections. This is brittle because Jetty supports more implementations ofConnection
on the server side thanHttpConnection
and there could in theory be an arbitrary implementation where we do not know whether it is a server or client connection (it could also be neither).This instead checks whether the package name contains
server
orclient
or neither. This is admittedly also brittle, but given the known implementations ofConnection
provided by the Jetty project, this pattern generally seems to hold, and it is at least more honest usingUNKNOWN
when our heuristic fails. It also avoids theNoClassDefFoundError
when usingJettyConnectionMetrics
with Jetty 12.Resolves gh-4324