Implement C3P0 connection pool metrics

[agoallikmaa]

No description provided.

[trask]

@jack-berg any thoughts on recording 0 vs not recording any value in this case?

[trask]

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:

opentelemetry-java-instrumentation/instrumentation-api-semconv/src/main/java/io/opentelemetry/instrumentation/api/metrics/db/DbConnectionPoolMetrics.java

Line 65 in fae88de

measurement.record(usedConnectionsGetter.getAsLong(), usedConnectionsAttributes));

[jack-berg]

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.

[agoallikmaa]

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.

[jack-berg]

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.

[trask]

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