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
While the specification defines which metrics should be contained in which scope it is not fully clear that each application would have its own base, vendor and application instance of the MetricRepository.
Most of the metrics described in MP specification refer to environment properties that would not be different for different applications suggesting that base and possibly vendor are "shared" for all applications. This however is not the case for the JAX-RS metrics or FT metrics which both are clearly related to a specific application but still belong to the base scope. This suggests that within an application context there should be a base, vendor and application instance of the MetricRepository. In that scenario the logical way to avoid duplication of the environment properties per application (which mostly would look wrong during export) would be to add a "global" base and vendorMetricRepository as well.
Another issue with only a "shared" or "global" base and vendor instance of the MetricRepository would be that when application related sources add to these "collisions" can occur where two different applications update the same shared metric. Also during export the relation to an application is lost and no _app tag could be added again suggesting that there should be a base and vendor instance for each application.
This issue should start the discussion how to make the specification less ambiguous when it comes to scopes and instances of MetricRepository in multi-application environments.
The text was updated successfully, but these errors were encountered:
Maybe the most obvious issue - with only a single base instance that exists throughout the life of the container different applications using the same class (for example bean classes used in TCK) will affect each other as the metrics never "reset".
@jbee , at this point the spec hasn't been specific about which metrics would be expected to be given an app label and which wouldn't. I expect that different server vendors have made different decisions on how to handle that. Perhaps first step on this could be to have different vendors that have multi-app servers show how they handle different metrics and see if we're already consistent or have differences to discuss?
@donbourne FYI: we moved towards base, vendor, application per application with an additional "global" context that only has base and vendor because this seemed the only logical way to implement what FT spec describes when it comes to metrics.
While the specification defines which metrics should be contained in which scope it is not fully clear that each application would have its own
base
,vendor
andapplication
instance of theMetricRepository
.Most of the metrics described in MP specification refer to environment properties that would not be different for different applications suggesting that
base
and possiblyvendor
are "shared" for all applications. This however is not the case for the JAX-RS metrics or FT metrics which both are clearly related to a specific application but still belong to thebase
scope. This suggests that within an application context there should be abase
,vendor
andapplication
instance of theMetricRepository
. In that scenario the logical way to avoid duplication of the environment properties per application (which mostly would look wrong during export) would be to add a "global"base
andvendor
MetricRepository
as well.Another issue with only a "shared" or "global"
base
andvendor
instance of theMetricRepository
would be that when application related sources add to these "collisions" can occur where two different applications update the same shared metric. Also during export the relation to an application is lost and no_app
tag could be added again suggesting that there should be abase
andvendor
instance for each application.This issue should start the discussion how to make the specification less ambiguous when it comes to scopes and instances of
MetricRepository
in multi-application environments.The text was updated successfully, but these errors were encountered: