You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I'm marking this as "question" because I am not sure if this is expected behavior, misuse on my end or an issue in the library.
I'm using this library to submit metrics to our open telemetry collector. When we shutdown our application, we are calling forceFlush on the StableMeterProviderSdk, which under the hood calls forceFlush() on the StablePeriodicMetricReaderSdk to ensure that we do not have any metric pending to send. StablePeriodicMetricReaderSdk.forceFlush() ends up calling func export(metrics : [StableMetricData]) -> ExportResult in StableOtlpHTTPMetricExporter.
The problem we are facing is that func export(metrics : [StableMetricData]) -> ExportResult performs the network call using the http client but it does not wait in any way for its completion. Instead it always returns .success . Oh the other hand, the flush method on StableOtlpHTTPMetricExporter does actually use a semaphore and waits for network call completion before returning.
Because of this behavior of not waiting, we are forced to introduce a sleep after calling forceFlush() to give some time to the request to go through.
I am not sure if I am misusing the SDK or if this is a bug or a work in progress.
Our code looks something like this (I based my implementation in the Stable Metric Example)
let exporter: StableOtlpHTTPMetricExporter = StableOtlpHTTPMetricExporter(endpoint: defaultStableOtlpHTTPMetricsEndpoint())
let reader: StableMetricReader = StablePeriodicMetricReaderBuilder(exporter: exporter).setInterval(timeInterval: TimeInterval(60)).build()
var meterProvider: StableMeterProviderSdk = StableMeterProviderBuilder()
.registerView(selector: InstrumentSelector.builder().setInstrument(name: ".*").build(), view: StableView.builder().build())
.registerMetricReader(reader:reader)
.build()
OpenTelemetry.registerStableMeterProvider(meterProvider: meterProvider)
let meter = OpenTelemetry.instance.stableMeterProvider?.meterBuilder(name: "SomeMeter").build()
var gaugeBuilder = meter!.gaugeBuilder(name: "demo_gauge").buildWithCallback({ ObservableDoubleMeasurement in
ObservableDoubleMeasurement.record(value: 1.0, attributes: ["some_attribute": AttributeValue.bool(true)])
})
let flushResult = meterProvider.forceFlush()
print(flushResult)
sleep(2) // <- Without this sleep call, the network request does not get time to trigger and the metric is never submitted.
I would expect that calling forceFlush waits until we get a response from the server.
The text was updated successfully, but these errors were encountered:
Hi, I'm marking this as "question" because I am not sure if this is expected behavior, misuse on my end or an issue in the library.
I'm using this library to submit metrics to our open telemetry collector. When we shutdown our application, we are calling forceFlush on the StableMeterProviderSdk, which under the hood calls forceFlush() on the StablePeriodicMetricReaderSdk to ensure that we do not have any metric pending to send. StablePeriodicMetricReaderSdk.forceFlush() ends up calling func export(metrics : [StableMetricData]) -> ExportResult in StableOtlpHTTPMetricExporter.
The problem we are facing is that
func export(metrics : [StableMetricData]) -> ExportResult
performs the network call using the http client but it does not wait in any way for its completion. Instead it always returns .success . Oh the other hand, the flush method on StableOtlpHTTPMetricExporter does actually use a semaphore and waits for network call completion before returning.Because of this behavior of not waiting, we are forced to introduce a sleep after calling forceFlush() to give some time to the request to go through.
I am not sure if I am misusing the SDK or if this is a bug or a work in progress.
Our code looks something like this (I based my implementation in the Stable Metric Example)
I would expect that calling forceFlush waits until we get a response from the server.
The text was updated successfully, but these errors were encountered: