splunk-apm-java: void io.opentelemetry.sdk.metrics.internal.SdkMeterProviderUtil.registerMetricReaderWithCardinalitySelector(...) java.lang.NoSuchMethodError

[aamielsan]

Background

We have an AWS Lambda function with a Java runtime and we're using the layer splunk-apm-java layer (i.e. arn:aws:lambda:eu-north-1:254067382080:layer:splunk-apm-java:15).

When we have a dependency that has a transitive dependency to either: io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi or io.opentelemetry:opentelemetry-sdk-extension-autoconfigure and pulls in a version later than 1.43.0, we're seeing this issue:

'void io.opentelemetry.sdk.metrics.internal.SdkMeterProviderUtil.registerMetricReaderWithCardinalitySelector(io.opentelemetry.sdk.metrics.SdkMeterProviderBuilder, io.opentelemetry.sdk.metrics.export.MetricReader, io.opentelemetry.sdk.metrics.internal.export.CardinalityLimitSelector)': java.lang.NoSuchMethodError

Possible cause

The registerMetricReaderWithCardinalitySelector method was removed in this change in open-telemetry/opentelemetry-java and was part of the v1.44.0 release.

After downloading the splunk-apm-java layer locally, it seems to be compiled and is expected to use the v1.43.0 version.

Questions

1. Do you have any plans to update the layer to use the latest versions and publish the updated layers in all supported regions?
2. I've also noticed in splunk-apm/splunk-apm-java.md that in us-east-2 the version is way higher than the other regions (i.e. arn:aws:lambda:us-east-2:254067382080:layer:splunk-apm-java:186). I'm just curious about why.

Workaround

As a current workaround, we've pinned our direct dependencies on releases that use both opentelemetry-sdk-extension-autoconfigure:1.43.0 and opentelemetry-sdk-extension-autoconfigure-spi:1.43.0 versions. This is not ideal given we want to use the latest features in one of our direct dependencies.

[johnbley]

To (1), yes, we will update. We don't necessarily have a set schedule for releasing updates; our all-in-one lambda layer pulls in so many transitive dependencies that keeping everything truly up-to-date would require near-daily releases!

For (2) the ARN number is so much higher because we use us-east-2 for our continuous integration tests - the build system uploads a new build (which gives it an incrementing ARN) and tests it against a suite of real lambda functions in a variety of languages and configurations. Those test builds don't get published to be publicly available, but they do increment that ARN number field. Combine that with dependabot automated PRs for updates and 📈. It does no real harm!