[
https://issues.apache.org/jira/browse/CXF-9177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francois LAZARUS updated CXF-9177:
----------------------------------
Description:
We are maintaining applications exposing SOAP and REST services using CXF.
Following the upgrade of CXF to versions 4.0.10 and 4.1.4, we noticed a loss of
server traffic metrics, which can be traced to changes done in the scope of
CXF-9170 ([https://github.com/apache/cxf/pull/2664]).
Our implementation relies on a custom Prometheus MetricsProvider, with similar
logic to
MicrometerMetricsProvider: #createEndpointContext returns null, while
#createOperationContext instantiates the actual context. (More on this below)
When going through the interceptor chain, the MetricsContext is successfully
created by the MetricsMessageInPreInvokeInterceptor in older versions of CXF.
In the latest ones, the guards implemented for CXF-9170 cause the
#createMetricsContextFor* method calls (themselves calling
MetricsProvider#createOperationContext) to be skipped.
Indeed, retrieving the context object from the exchange here can result in
retrieving an empty list:
[https://github.com/apache/cxf/commit/fa7fc1214d1c50be6eaef4be18f46dd3f00dbae9#diff-6e30f58960271bb32e081e90dfd177776cfd827a5f3aac70299164b72bad71c5R193]
The list is created in AbstractMetricsInterceptor#createEndpointMetrics, left
empty because the MetricsProvider returns null in #createEndpointContext and
added to the exchange before leaving the method.
With an empty list, blocks guarded by null checks in
AbstractMetricsInterceptor#addOperationMetrics are no longer entered.
The implementation of MicrometerMetricsProvider has changed in these new
versions, also instantiating the context immediately in createEndpointContext.
Our implementation cannot do the same, because we need to distinguish SOAP and
REST operations to populate labels, and are relying on the
createOperationContext and createResourceContext methods of the MetricsProvider
to achieve this.
was:
We are maintaining applications exposing SOAP and REST services using CXF.
Following the upgrade of CXF to versions 4.0.10 and 4.1.4, we noticed a loss of
server traffic metrics, which can be traced to changes done in the scope of
CXF-9170 ([https://github.com/apache/cxf/pull/2664]).
Our implementation relies on a custom Prometheus MetricsProvider, with similar
logic to
MicrometerMetricsProvider: #createEndpointContext returns null, while
#createOperationContext instantiates the actual context. (More on this below)
When going through the interceptor chain, the MetricsContext is successfully
created by the MetricsMessageInPreInvokeInterceptor in older versions of CXF.
In the latest ones, the guards implemented for CXF-9170 cause the
#createMetricsContextFor* method calls (themselves calling
MetricsProvider#createOperationContext) to be skipped.
Indeed, retrieving the context object from the exchange here can result in
retrieving an empty list:
[https://github.com/apache/cxf/commit/fa7fc1214d1c50be6eaef4be18f46dd3f00dbae9#diff-6e30f58960271bb32e081e90dfd177776cfd827a5f3aac70299164b72bad71c5R193]
The list is created in AbstractMetricsInterceptor#createEndpointMetrics, left
empty because the MetricsProvider returns null in #createEndpointContext and
added to the exchange before leaving the method.
With an empty list, blocks guarded by null checks in
AbstractMetricsInterceptor#addOperationMetrics are no longer entered.
The implementation of MicrometerMetricsProvider has changed in these new
versions, also instantiating the context immediately in createEndpointContext.
Our implementation cannot do the same, because we need to distinguish SOAP and
REST operations to populate labels, and are relying on the
createOperationContext and createResourceContext methods of the MetricsProvider
to achieve this.
> Regression in CXF 4.0.10 and 4.1.4 server metrics creation
> ----------------------------------------------------------
>
> Key: CXF-9177
> URL: https://issues.apache.org/jira/browse/CXF-9177
> Project: CXF
> Issue Type: Bug
> Affects Versions: 4.1.4, 4.0.10
> Reporter: Francois LAZARUS
> Priority: Major
>
> We are maintaining applications exposing SOAP and REST services using CXF.
> Following the upgrade of CXF to versions 4.0.10 and 4.1.4, we noticed a loss
> of server traffic metrics, which can be traced to changes done in the scope
> of CXF-9170 ([https://github.com/apache/cxf/pull/2664]).
> Our implementation relies on a custom Prometheus MetricsProvider, with
> similar logic to
> MicrometerMetricsProvider: #createEndpointContext returns null, while
> #createOperationContext instantiates the actual context. (More on this below)
> When going through the interceptor chain, the MetricsContext is successfully
> created by the MetricsMessageInPreInvokeInterceptor in older versions of CXF.
> In the latest ones, the guards implemented for CXF-9170 cause the
> #createMetricsContextFor* method calls (themselves calling
> MetricsProvider#createOperationContext) to be skipped.
> Indeed, retrieving the context object from the exchange here can result in
> retrieving an empty list:
> [https://github.com/apache/cxf/commit/fa7fc1214d1c50be6eaef4be18f46dd3f00dbae9#diff-6e30f58960271bb32e081e90dfd177776cfd827a5f3aac70299164b72bad71c5R193]
> The list is created in AbstractMetricsInterceptor#createEndpointMetrics, left
> empty because the MetricsProvider returns null in #createEndpointContext and
> added to the exchange before leaving the method.
> With an empty list, blocks guarded by null checks in
> AbstractMetricsInterceptor#addOperationMetrics are no longer entered.
> The implementation of MicrometerMetricsProvider has changed in these new
> versions, also instantiating the context immediately in createEndpointContext.
> Our implementation cannot do the same, because we need to distinguish SOAP
> and REST operations to populate labels, and are relying on the
> createOperationContext and createResourceContext methods of the
> MetricsProvider to achieve this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
