Summary
The Java metrics SDK now has batching support in PeriodicMetricReader via maxExportBatchSize, but it still appears to lack reader-level timeout enforcement for metric exports.
This matters because the metrics spec now treats exportTimeoutMillis and maxExportBatchSize together on the periodic exporting metric reader, and requires the timeout to apply to each individual export request.
Spec reference:
Current Java behavior
From code inspection:
PeriodicMetricReaderBuilder exposes setInterval(...), setExecutor(...), and setMaxExportBatchSize(...), but no reader-level export timeout configuration.PeriodicMetricReader serializes batched export(...) calls, but it does not apply a timeout budget around each batch export itself.- Some exporters (for example OTLP metric exporters) have their own exporter/network timeout settings, so per-request timeout may happen in practice there, but that is exporter-specific behavior rather than
PeriodicMetricReader behavior.
- By contrast, Java's
BatchSpanProcessor and BatchLogRecordProcessor do explicitly join export results with an exporter timeout.
Why this seems like a gap
The merged metrics spec text says the periodic reader has:
exportIntervalMillisexportTimeoutMillis- development-status
maxExportBatchSize
and that:
- batches must be exported serially
- timeout applies to individual requests
ForceFlush should collect, split into batches if needed, export each batch, call exporter ForceFlush, and report success/failure/timeout
Java seems aligned on serial batching/order, but not on reader-level timeout enforcement.
Questions
- Should Java metrics add a reader-level timeout configuration on
PeriodicMetricReaderBuilder to align with the spec model?
- Should that timeout be enforced per batch in both scheduled export and
forceFlush() paths?
- Should timeout handling mirror the existing trace/logs processors as closely as possible?
- If exporter-specific timeout already exists (e.g. OTLP), is that considered sufficient for now, or should the reader still own timeout semantics explicitly?
Related
Summary
The Java metrics SDK now has batching support in
PeriodicMetricReaderviamaxExportBatchSize, but it still appears to lack reader-level timeout enforcement for metric exports.This matters because the metrics spec now treats
exportTimeoutMillisandmaxExportBatchSizetogether on the periodic exporting metric reader, and requires the timeout to apply to each individual export request.Spec reference:
Current Java behavior
From code inspection:
PeriodicMetricReaderBuilderexposessetInterval(...),setExecutor(...), andsetMaxExportBatchSize(...), but no reader-level export timeout configuration.PeriodicMetricReaderserializes batchedexport(...)calls, but it does not apply a timeout budget around each batch export itself.PeriodicMetricReaderbehavior.BatchSpanProcessorandBatchLogRecordProcessordo explicitly join export results with an exporter timeout.Why this seems like a gap
The merged metrics spec text says the periodic reader has:
exportIntervalMillisexportTimeoutMillismaxExportBatchSizeand that:
ForceFlushshould collect, split into batches if needed, export each batch, call exporterForceFlush, and report success/failure/timeoutJava seems aligned on serial batching/order, but not on reader-level timeout enforcement.
Questions
PeriodicMetricReaderBuilderto align with the spec model?forceFlush()paths?Related