-
Notifications
You must be signed in to change notification settings - Fork 873
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
Implement C3P0 connection pool metrics #6174
Conversation
try { | ||
return supplier.getAsInt(); | ||
} catch (SQLException e) { | ||
return 0; |
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.
@jack-berg any thoughts on recording 0
vs not recording any value in this case?
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.
I'm thinking it may be better to re-throw an unchecked exception here instead of recording 0
.
It looks like it will get caught and logged here: https://github.com/open-telemetry/opentelemetry-java/blob/f280f278be0222f24b7ad7a8dc7ffc293358785b/sdk/metrics/src/main/java/io/opentelemetry/sdk/metrics/internal/state/CallbackRegistration.java#L100-L103
Or if we think this is common and don't want to log, we could consider suppressing it here:
Line 65 in fae88de
measurement.record(usedConnectionsGetter.getAsLong(), usedConnectionsAttributes)); |
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.
Probably don't want instrumentation to be in the habit of throwing exceptions, even if the SDK can handle it. Better to have the handling to be explicit in the callback.
I do think that recording nothing is more accurate than 0.
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.
The problem is that the only ways to record nothing with the current implementation of DbConnectionPoolMetrics
would be to either throw an exception, or change DbConnectionPoolMetrics
to use providers that return a Long
instead that can be null
. I changed it throw since I didn't see the last comment yet, but if you can suggest a better way, I can change it.
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.
Do you expect exception to be thrown here on a regular basis? If so, it is likely to make user logs noisy. For reference, here's the code that handles these exceptions.
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.
I looked briefly at the c3p0 implementation, and I couldn't really find any case where these exceptions would really be thrown, so I think it's probably ok
No description provided.