Two possible clarifications we could add to the spec:
What exact duration does an optional JAX-RS metric measure?
How quickly can clients expect the metrics available via /metrics to reflect metrics updates?
The spec leaves open exactly what time interval the JAX-RS metrics measure. Any change to the spec and any impls must be a bit careful, because JAX-RS methods can be asynchronous so an interceptor would not bracket the entire processing time, just the time to get the operation started. Perhaps the spec could state something like the measured processing time accumulates from the time control enters the JAX-RS endpoint method to approximately the time a JAX-RS container response filter is invoked. That does not exactly mandate an implementation, the "approximate" wording leaving open the possibility that an implementation might choose a different implementation that could yield slightly different results as compared to other implementations.
Related but separate is the question of the timing of when updates to the JAX-RS metrics in particular, and potentially to any metric in general, become visible in the registry and to clients accessing the /metrics endpoint. One could imagine an implementation that captures the correct data (e.g., for the JAX-RS metrics) does not apply per-request metrics updates until the response actually departs the server for the client. This might be to allow metrics to measure more of the actual time the server as a whole processes the request, or to get the metrics update code out of the request-to-response code path for throughput reasons, or for other purposes.
Two possible clarifications we could add to the spec:
/metricsto reflect metrics updates?The spec leaves open exactly what time interval the JAX-RS metrics measure. Any change to the spec and any impls must be a bit careful, because JAX-RS methods can be asynchronous so an interceptor would not bracket the entire processing time, just the time to get the operation started. Perhaps the spec could state something like the measured processing time accumulates from the time control enters the JAX-RS endpoint method to approximately the time a JAX-RS container response filter is invoked. That does not exactly mandate an implementation, the "approximate" wording leaving open the possibility that an implementation might choose a different implementation that could yield slightly different results as compared to other implementations.
Related but separate is the question of the timing of when updates to the JAX-RS metrics in particular, and potentially to any metric in general, become visible in the registry and to clients accessing the
/metricsendpoint. One could imagine an implementation that captures the correct data (e.g., for the JAX-RS metrics) does not apply per-request metrics updates until the response actually departs the server for the client. This might be to allow metrics to measure more of the actual time the server as a whole processes the request, or to get the metrics update code out of the request-to-response code path for throughput reasons, or for other purposes.