Metrics: clarify and align PeriodicMetricReader export timeout semantics with batching spec

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:

• open-telemetry/opentelemetry-specification#4895

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:

• exportIntervalMillis
• exportTimeoutMillis
• 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

• open-telemetry/opentelemetry-java#8296
• Follow-up correctness/complexity fix against the PR branch: https://github.com/psx95/opentelemetry-java/pull/5

Start with PeriodicMetricReaderBuilder and PeriodicMetricReader to verify the current batching and export paths. Compare their behavior with BatchSpanProcessor and BatchLogRecordProcessor, then read specification#4895 and the related issue and pull request. Done means the Java behavior and configuration decisions are explicitly aligned with the spec for scheduled exports and forceFlush().