[
https://issues.apache.org/jira/browse/CXF-8367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Berger updated CXF-8367:
-------------------------------
Description:
When I use the new MetricsFeature introduced in CXF-8213, the metrics look like
this in positive cases:
{code:java}
cxf_server_requests_seconds_count{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
1.0
cxf_server_requests_seconds_sum{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
0.221690028
{code}
In this case, Message.RESPONSE_CODE is null when the
MetricsMessageOutInterceptor is called.
In success cases, this Message attribute is set in the
MessageSenderEndingInterceptor when
AbstractHTTPDestination.getResponseCodeFromMessage() is called.
MetricsMessageOutInterceptor is called before that interceptor, that's why
Message.RESPONSE_CODE is not set.
There are 2 solution options, as far as I understand:
# Move the MetricsMessageOutInterceptor after the
MessageSenderEndingInterceptor (the consequences of that are unknown to me)
# Adjust the StandardTags.status() method to treat null values as 200
There's also another problem of the faultCode being LOGICAL_RUNTIME_FAULT in my
success cases. This is because the MAPAggregatorImpl always calls
exchange.setOutFaultMessage(). The code inside of
JaxwsFaultCodeProvider.getFaultCode() assumes that ex.getOutFaultMessage() !=
null indicates a Fault.
was:
When I use the new MetricsFeature introduced in CXF-8213, the metrics look like
this in positive cases:
{code:java}
cxf_server_requests_seconds_count{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
1.0
cxf_server_requests_seconds_sum{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
0.221690028
{code}
In this case, Message.RESPONSE_CODE is null when the
MetricsMessageOutInterceptor is called.
In success cases, this Message attribute is set in the
MessageSenderEndingInterceptor when
AbstractHTTPDestination.getResponseCodeFromMessage() is called.
MetricsMessageOutInterceptor is called before that interceptor, that's why
Message.RESPONSE_CODE is not set.
There are 2 solution options, as far as I understand:
# Move the MetricsMessageOutInterceptor after the
MessageSenderEndingInterceptor (the consequences of that are unknown to me)
# Adjust the StandardTags.status() method to treat null values as 200
> Micrometer always reports OUTCOME=UNKNOWN
> -----------------------------------------
>
> Key: CXF-8367
> URL: https://issues.apache.org/jira/browse/CXF-8367
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
> Affects Versions: 3.4.1
> Reporter: Stefan Berger
> Priority: Major
>
> When I use the new MetricsFeature introduced in CXF-8213, the metrics look
> like this in positive cases:
> {code:java}
> cxf_server_requests_seconds_count{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
> 1.0
> cxf_server_requests_seconds_sum{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
> 0.221690028
> {code}
> In this case, Message.RESPONSE_CODE is null when the
> MetricsMessageOutInterceptor is called.
> In success cases, this Message attribute is set in the
> MessageSenderEndingInterceptor when
> AbstractHTTPDestination.getResponseCodeFromMessage() is called.
> MetricsMessageOutInterceptor is called before that interceptor, that's why
> Message.RESPONSE_CODE is not set.
> There are 2 solution options, as far as I understand:
> # Move the MetricsMessageOutInterceptor after the
> MessageSenderEndingInterceptor (the consequences of that are unknown to me)
> # Adjust the StandardTags.status() method to treat null values as 200
>
> There's also another problem of the faultCode being LOGICAL_RUNTIME_FAULT in
> my success cases. This is because the MAPAggregatorImpl always calls
> exchange.setOutFaultMessage(). The code inside of
> JaxwsFaultCodeProvider.getFaultCode() assumes that ex.getOutFaultMessage() !=
> null indicates a Fault.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
