[jira] [Commented] (CXF-8124) CXF metrics - MetricsContext#stop called twice or without Fault in certain error cases
[ https://issues.apache.org/jira/browse/CXF-8124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16952902#comment-16952902 ] Emile de Weerd commented on CXF-8124: - Hi [~reta], thank you for you reactivity! I saw the new tests part of the opened PRs, they look like the snippet of code provided here :) I took the latest master code, built it and ran the test against it. One of the 2 use cases has been indeed fixed: *notFoundStatusCode_stopCalledOnceWithFaultObjectInExchange* However the other is still failing. As this is kind of my fault of not having opened another issue for this other case, I will close this issue and open another one. Hope this is satisfactory. > CXF metrics - MetricsContext#stop called twice or without Fault in certain > error cases > -- > > Key: CXF-8124 > URL: https://issues.apache.org/jira/browse/CXF-8124 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.18, 3.3.3 >Reporter: Emile de Weerd >Assignee: Andriy Redko >Priority: Major > Fix For: 3.4.0, 3.2.11, 3.3.4 > > Attachments: cxf-metrics-context-stop-issue.tar.xz > > Time Spent: 20m > Remaining Estimate: 0h > > While using the CXF metrics feature with a CXF REST client, in some situation > there are incoherent calls to the MetricsContext#stop method. 2 cases can be > isolated: server returns a 404 and the response body transmission is > interrupted in the middle of the transfer. > I wrote a unit test that allows to clearly reproduce the 2 use cases. Of > course they are failing. The test prints out a stacktrace per call to the > MetricsContext#stop method. > *notFoundStatusCode_stopCalledOnceWithFaultObjectInExchange* > [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - > MetricsContext#stop called 2 times > [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called > with time = 16408651 ns, inSize = -1, outSize = 0, exchange that contains a > FaultMode = false; callad at: > [...] > at > org.apache.cxf.metrics.MetricsContext$$EnhancerByMockitoWithCGLIB$$1997d2d2.stop() > at org.apache.cxf.metrics.ExchangeMetrics.stop(ExchangeMetrics.java:75) > at > org.apache.cxf.metrics.interceptors.AbstractMetricsInterceptor.stop(AbstractMetricsInterceptor.java:215) > at > org.apache.cxf.metrics.interceptors.MetricsMessageInPostInvokeInterceptor.handleMessage(MetricsMessageInPostInvokeInterceptor.java:34) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at > org.apache.cxf.jaxrs.client.ClientMessageObserver.onMessage(ClientMessageObserver.java:56) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1693) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1570) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1371) > at > org.apache.cxf.io.AbstractWrappedOutputStream.close(AbstractWrappedOutputStream.java:77) > at > org.apache.cxf.metrics.interceptors.CountingOutputStream.close(CountingOutputStream.java:47) > at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:671) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at > org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain(AbstractClient.java:709) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:887) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:335) > at com.sun.proxy.$Proxy22.getBook(Unknown Source) > at > cxf.reproducers.CxfMetricsIssueReproducerTest.notFoundStatusCode_stopCalledOnceWithFaultObjectInExchange(CxfMetricsIssueReproducerTest.java:151) > [...] > [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called > with time = 26412378 ns, inSize = -1, outSize = 0, exchange that contains a > FaultMode = true; callad at: > [...] > at > org.apache.cxf.metrics.MetricsContext$$EnhancerByMockitoWithCGLIB$$1997d2d2.stop() > at org.apache.cxf.metrics.ExchangeMetrics.stop(ExchangeMetrics.java:75) > at > org.apache.cxf.metrics.interceptors.AbstractMetricsInterceptor.stop(AbstractMetricsInterceptor.java:215) > at > org.apache.cxf.metrics.interceptors.MetricsMessageInPostInvokeInterceptor.handleMessage(MetricsMessageInPostInvokeInterceptor.java:34) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
[jira] [Closed] (CXF-8124) CXF metrics - MetricsContext#stop called twice or without Fault in certain error cases
[ https://issues.apache.org/jira/browse/CXF-8124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emile de Weerd closed CXF-8124. --- Estimated Complexity: Moderate (was: Unknown) Checked *notFoundStatusCode_stopCalledOnceWithFaultObjectInExchange* test case and it is passing with latest master code. > CXF metrics - MetricsContext#stop called twice or without Fault in certain > error cases > -- > > Key: CXF-8124 > URL: https://issues.apache.org/jira/browse/CXF-8124 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.18, 3.3.3 >Reporter: Emile de Weerd >Assignee: Andriy Redko >Priority: Major > Fix For: 3.4.0, 3.2.11, 3.3.4 > > Attachments: cxf-metrics-context-stop-issue.tar.xz > > Time Spent: 20m > Remaining Estimate: 0h > > While using the CXF metrics feature with a CXF REST client, in some situation > there are incoherent calls to the MetricsContext#stop method. 2 cases can be > isolated: server returns a 404 and the response body transmission is > interrupted in the middle of the transfer. > I wrote a unit test that allows to clearly reproduce the 2 use cases. Of > course they are failing. The test prints out a stacktrace per call to the > MetricsContext#stop method. > *notFoundStatusCode_stopCalledOnceWithFaultObjectInExchange* > [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - > MetricsContext#stop called 2 times > [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called > with time = 16408651 ns, inSize = -1, outSize = 0, exchange that contains a > FaultMode = false; callad at: > [...] > at > org.apache.cxf.metrics.MetricsContext$$EnhancerByMockitoWithCGLIB$$1997d2d2.stop() > at org.apache.cxf.metrics.ExchangeMetrics.stop(ExchangeMetrics.java:75) > at > org.apache.cxf.metrics.interceptors.AbstractMetricsInterceptor.stop(AbstractMetricsInterceptor.java:215) > at > org.apache.cxf.metrics.interceptors.MetricsMessageInPostInvokeInterceptor.handleMessage(MetricsMessageInPostInvokeInterceptor.java:34) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at > org.apache.cxf.jaxrs.client.ClientMessageObserver.onMessage(ClientMessageObserver.java:56) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1693) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1570) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1371) > at > org.apache.cxf.io.AbstractWrappedOutputStream.close(AbstractWrappedOutputStream.java:77) > at > org.apache.cxf.metrics.interceptors.CountingOutputStream.close(CountingOutputStream.java:47) > at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:671) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at > org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain(AbstractClient.java:709) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:887) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:335) > at com.sun.proxy.$Proxy22.getBook(Unknown Source) > at > cxf.reproducers.CxfMetricsIssueReproducerTest.notFoundStatusCode_stopCalledOnceWithFaultObjectInExchange(CxfMetricsIssueReproducerTest.java:151) > [...] > [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called > with time = 26412378 ns, inSize = -1, outSize = 0, exchange that contains a > FaultMode = true; callad at: > [...] > at > org.apache.cxf.metrics.MetricsContext$$EnhancerByMockitoWithCGLIB$$1997d2d2.stop() > at org.apache.cxf.metrics.ExchangeMetrics.stop(ExchangeMetrics.java:75) > at > org.apache.cxf.metrics.interceptors.AbstractMetricsInterceptor.stop(AbstractMetricsInterceptor.java:215) > at > org.apache.cxf.metrics.interceptors.MetricsMessageInPostInvokeInterceptor.handleMessage(MetricsMessageInPostInvokeInterceptor.java:34) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at > org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:112) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.checkResponse(ClientProxyImpl.java:434) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:990) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocat
[jira] [Created] (CXF-8132) CXF metrics - No FaultMode in Exchange for response timeout during reception of payload
Emile de Weerd created CXF-8132: --- Summary: CXF metrics - No FaultMode in Exchange for response timeout during reception of payload Key: CXF-8132 URL: https://issues.apache.org/jira/browse/CXF-8132 Project: CXF Issue Type: Bug Components: Core Affects Versions: 3.1.18, 3.3.3 Reporter: Emile de Weerd Assignee: Andriy Redko Fix For: 3.4.0, 3.2.11, 3.3.4 While using the CXF metrics feature with a CXF REST client, in some situation there are incoherent calls to the MetricsContext#stop method. 2 cases can be isolated: server returns a 404 and the response body transmission is interrupted in the middle of the transfer. I wrote a unit test that allows to clearly reproduce the 2 use cases. Of course they are failing. The test prints out a stacktrace per call to the MetricsContext#stop method. *notFoundStatusCode_stopCalledOnceWithFaultObjectInExchange* [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - MetricsContext#stop called 2 times [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called with time = 16408651 ns, inSize = -1, outSize = 0, exchange that contains a FaultMode = false; callad at: [...] at org.apache.cxf.metrics.MetricsContext$$EnhancerByMockitoWithCGLIB$$1997d2d2.stop() at org.apache.cxf.metrics.ExchangeMetrics.stop(ExchangeMetrics.java:75) at org.apache.cxf.metrics.interceptors.AbstractMetricsInterceptor.stop(AbstractMetricsInterceptor.java:215) at org.apache.cxf.metrics.interceptors.MetricsMessageInPostInvokeInterceptor.handleMessage(MetricsMessageInPostInvokeInterceptor.java:34) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) at org.apache.cxf.jaxrs.client.ClientMessageObserver.onMessage(ClientMessageObserver.java:56) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1693) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1570) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1371) at org.apache.cxf.io.AbstractWrappedOutputStream.close(AbstractWrappedOutputStream.java:77) at org.apache.cxf.metrics.interceptors.CountingOutputStream.close(CountingOutputStream.java:47) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:671) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) at org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain(AbstractClient.java:709) at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:887) at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:335) at com.sun.proxy.$Proxy22.getBook(Unknown Source) at cxf.reproducers.CxfMetricsIssueReproducerTest.notFoundStatusCode_stopCalledOnceWithFaultObjectInExchange(CxfMetricsIssueReproducerTest.java:151) [...] [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called with time = 26412378 ns, inSize = -1, outSize = 0, exchange that contains a FaultMode = true; callad at: [...] at org.apache.cxf.metrics.MetricsContext$$EnhancerByMockitoWithCGLIB$$1997d2d2.stop() at org.apache.cxf.metrics.ExchangeMetrics.stop(ExchangeMetrics.java:75) at org.apache.cxf.metrics.interceptors.AbstractMetricsInterceptor.stop(AbstractMetricsInterceptor.java:215) at org.apache.cxf.metrics.interceptors.MetricsMessageInPostInvokeInterceptor.handleMessage(MetricsMessageInPostInvokeInterceptor.java:34) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:112) at org.apache.cxf.jaxrs.client.ClientProxyImpl.checkResponse(ClientProxyImpl.java:434) at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:990) at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:895) at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:335) at com.sun.proxy.$Proxy22.getBook(Unknown Source) at cxf.reproducers.CxfMetricsIssueReproducerTest.notFoundStatusCode_stopCalledOnceWithFaultObjectInExchange(CxfMetricsIssueReproducerTest.java:151) [...] *incompleteResponse_stopCalledOnceWithFaultObjectInExchange* [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - MetricsContext#stop called 1 times [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called with time = 14901568 ns, inSize = -1, outSize = 0, exchange that contains a FaultMode = false; callad at: [...]
[jira] [Updated] (CXF-8132) CXF metrics - No FaultMode in Exchange for response timeout during reception of payload
[ https://issues.apache.org/jira/browse/CXF-8132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emile de Weerd updated CXF-8132: Fix Version/s: (was: 3.2.11) (was: 3.3.4) (was: 3.4.0) Description: While using the CXF metrics feature with a CXF REST client, in some error case there is not FaultMode inside the Exchange object passed to the MetricsContext#stop method. The use case is when the response body transmission is interrupted in the middle of the transfer. I wrote a unit test that allows to clearly reproduce. It is failing. The Unit test prints out stacktraces whenever start or stop are called from the MetricsContext. *incompleteResponse_stopCalledOnceWithFaultObjectInExchange* [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - MetricsContext#stop called 1 times [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called with time = 14901568 ns, inSize = -1, outSize = 0, exchange that contains a FaultMode = false; callad at: [...] at org.apache.cxf.metrics.MetricsContext$$EnhancerByMockitoWithCGLIB$$1997d2d2.stop() at org.apache.cxf.metrics.ExchangeMetrics.stop(ExchangeMetrics.java:75) at org.apache.cxf.metrics.interceptors.AbstractMetricsInterceptor.stop(AbstractMetricsInterceptor.java:215) at org.apache.cxf.metrics.interceptors.MetricsMessageInPostInvokeInterceptor.handleMessage(MetricsMessageInPostInvokeInterceptor.java:34) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) at org.apache.cxf.jaxrs.client.ClientMessageObserver.onMessage(ClientMessageObserver.java:56) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1693) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1570) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1371) at org.apache.cxf.io.AbstractWrappedOutputStream.close(AbstractWrappedOutputStream.java:77) at org.apache.cxf.metrics.interceptors.CountingOutputStream.close(CountingOutputStream.java:47) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:671) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) at org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain(AbstractClient.java:709) at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:887) at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:335) at com.sun.proxy.$Proxy22.getBook(Unknown Source) at cxf.reproducers.CxfMetricsIssueReproducerTest.incompleteResponse_stopCalledOnceWithFaultObjectInExchange(CxfMetricsIssueReproducerTest.java:171) [...] I am not sure the test case makes sense, maybe that is the first part to review. was: While using the CXF metrics feature with a CXF REST client, in some situation there are incoherent calls to the MetricsContext#stop method. 2 cases can be isolated: server returns a 404 and the response body transmission is interrupted in the middle of the transfer. I wrote a unit test that allows to clearly reproduce the 2 use cases. Of course they are failing. The test prints out a stacktrace per call to the MetricsContext#stop method. *notFoundStatusCode_stopCalledOnceWithFaultObjectInExchange* [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - MetricsContext#stop called 2 times [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called with time = 16408651 ns, inSize = -1, outSize = 0, exchange that contains a FaultMode = false; callad at: [...] at org.apache.cxf.metrics.MetricsContext$$EnhancerByMockitoWithCGLIB$$1997d2d2.stop() at org.apache.cxf.metrics.ExchangeMetrics.stop(ExchangeMetrics.java:75) at org.apache.cxf.metrics.interceptors.AbstractMetricsInterceptor.stop(AbstractMetricsInterceptor.java:215) at org.apache.cxf.metrics.interceptors.MetricsMessageInPostInvokeInterceptor.handleMessage(MetricsMessageInPostInvokeInterceptor.java:34) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) at org.apache.cxf.jaxrs.client.ClientMessageObserver.onMessage(ClientMessageObserver.java:56) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1693) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1570) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1371) at org.apache.cxf.io.AbstractWrappedOutputStream.close(AbstractWrappedOutputStream.java:77) at org.apache.cxf.metrics.inte
[jira] [Updated] (CXF-8132) CXF metrics - No FaultMode in Exchange for response timeout during reception of payload
[ https://issues.apache.org/jira/browse/CXF-8132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emile de Weerd updated CXF-8132: Attachment: cxf-metrics-context-response-timeout-issue.tar.xz > CXF metrics - No FaultMode in Exchange for response timeout during reception > of payload > --- > > Key: CXF-8132 > URL: https://issues.apache.org/jira/browse/CXF-8132 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.18, 3.3.3 >Reporter: Emile de Weerd >Assignee: Andriy Redko >Priority: Major > Attachments: cxf-metrics-context-response-timeout-issue.tar.xz > > > While using the CXF metrics feature with a CXF REST client, in some error > case there is not FaultMode inside the Exchange object passed to the > MetricsContext#stop method. The use case is when the response body > transmission is interrupted in the middle of the transfer. > I wrote a unit test that allows to clearly reproduce. It is failing. The Unit > test prints out stacktraces whenever start or stop are called from the > MetricsContext. > *incompleteResponse_stopCalledOnceWithFaultObjectInExchange* > [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - > MetricsContext#stop called 1 times > [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called > with time = 14901568 ns, inSize = -1, outSize = 0, exchange that contains a > FaultMode = false; callad at: > [...] > at > org.apache.cxf.metrics.MetricsContext$$EnhancerByMockitoWithCGLIB$$1997d2d2.stop() > at org.apache.cxf.metrics.ExchangeMetrics.stop(ExchangeMetrics.java:75) > at > org.apache.cxf.metrics.interceptors.AbstractMetricsInterceptor.stop(AbstractMetricsInterceptor.java:215) > at > org.apache.cxf.metrics.interceptors.MetricsMessageInPostInvokeInterceptor.handleMessage(MetricsMessageInPostInvokeInterceptor.java:34) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at > org.apache.cxf.jaxrs.client.ClientMessageObserver.onMessage(ClientMessageObserver.java:56) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1693) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1570) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1371) > at > org.apache.cxf.io.AbstractWrappedOutputStream.close(AbstractWrappedOutputStream.java:77) > at > org.apache.cxf.metrics.interceptors.CountingOutputStream.close(CountingOutputStream.java:47) > at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:671) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at > org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain(AbstractClient.java:709) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:887) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:335) > at com.sun.proxy.$Proxy22.getBook(Unknown Source) > at > cxf.reproducers.CxfMetricsIssueReproducerTest.incompleteResponse_stopCalledOnceWithFaultObjectInExchange(CxfMetricsIssueReproducerTest.java:171) > [...] > I am not sure the test case makes sense, maybe that is the first part to > review. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CXF-8124) CXF metrics - MetricsContext#stop called twice or without Fault in certain error cases
[ https://issues.apache.org/jira/browse/CXF-8124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953264#comment-16953264 ] Andriy Redko commented on CXF-8124: --- Thanks for confirming the fix, [~mederel]! > CXF metrics - MetricsContext#stop called twice or without Fault in certain > error cases > -- > > Key: CXF-8124 > URL: https://issues.apache.org/jira/browse/CXF-8124 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.18, 3.3.3 >Reporter: Emile de Weerd >Assignee: Andriy Redko >Priority: Major > Fix For: 3.4.0, 3.2.11, 3.3.4 > > Attachments: cxf-metrics-context-stop-issue.tar.xz > > Time Spent: 20m > Remaining Estimate: 0h > > While using the CXF metrics feature with a CXF REST client, in some situation > there are incoherent calls to the MetricsContext#stop method. 2 cases can be > isolated: server returns a 404 and the response body transmission is > interrupted in the middle of the transfer. > I wrote a unit test that allows to clearly reproduce the 2 use cases. Of > course they are failing. The test prints out a stacktrace per call to the > MetricsContext#stop method. > *notFoundStatusCode_stopCalledOnceWithFaultObjectInExchange* > [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - > MetricsContext#stop called 2 times > [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called > with time = 16408651 ns, inSize = -1, outSize = 0, exchange that contains a > FaultMode = false; callad at: > [...] > at > org.apache.cxf.metrics.MetricsContext$$EnhancerByMockitoWithCGLIB$$1997d2d2.stop() > at org.apache.cxf.metrics.ExchangeMetrics.stop(ExchangeMetrics.java:75) > at > org.apache.cxf.metrics.interceptors.AbstractMetricsInterceptor.stop(AbstractMetricsInterceptor.java:215) > at > org.apache.cxf.metrics.interceptors.MetricsMessageInPostInvokeInterceptor.handleMessage(MetricsMessageInPostInvokeInterceptor.java:34) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at > org.apache.cxf.jaxrs.client.ClientMessageObserver.onMessage(ClientMessageObserver.java:56) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1693) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1570) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1371) > at > org.apache.cxf.io.AbstractWrappedOutputStream.close(AbstractWrappedOutputStream.java:77) > at > org.apache.cxf.metrics.interceptors.CountingOutputStream.close(CountingOutputStream.java:47) > at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:671) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at > org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain(AbstractClient.java:709) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:887) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:335) > at com.sun.proxy.$Proxy22.getBook(Unknown Source) > at > cxf.reproducers.CxfMetricsIssueReproducerTest.notFoundStatusCode_stopCalledOnceWithFaultObjectInExchange(CxfMetricsIssueReproducerTest.java:151) > [...] > [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called > with time = 26412378 ns, inSize = -1, outSize = 0, exchange that contains a > FaultMode = true; callad at: > [...] > at > org.apache.cxf.metrics.MetricsContext$$EnhancerByMockitoWithCGLIB$$1997d2d2.stop() > at org.apache.cxf.metrics.ExchangeMetrics.stop(ExchangeMetrics.java:75) > at > org.apache.cxf.metrics.interceptors.AbstractMetricsInterceptor.stop(AbstractMetricsInterceptor.java:215) > at > org.apache.cxf.metrics.interceptors.MetricsMessageInPostInvokeInterceptor.handleMessage(MetricsMessageInPostInvokeInterceptor.java:34) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at > org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:112) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.checkResponse(ClientProxyImpl.java:434) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:990) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:895) > at > org.apache.cxf.jaxrs.client.ClientPro
[jira] [Commented] (CXF-8132) CXF metrics - No FaultMode in Exchange for response timeout during reception of payload
[
https://issues.apache.org/jira/browse/CXF-8132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953289#comment-16953289
]
Andriy Redko commented on CXF-8132:
---
Hi [~mederel],
I don't think that the test represents the valid use case to be honest. First
of all, the transmission is not interrupted, the mock is configured to send
only part of the response:
{code:java}
httpServer.when(request().withPath("/books/10").withHeader("Content-Type",
MediaType.APPLICATION_JSON))
.error(HttpError.error().withDropConnection(false)
.withResponseBytes(ArrayUtils.subarray(normalAnswerBytes, 0,
normalAnswerBytes.length - 15)));
{code}
Secondly, the client receives the HTTP/200 from server and this is where the
MetricsContext::stop() is called: exactly when the server replies, but . So
from my perspective, the CXF does proper thing. The fault should not be set in
the exchange since it happens only when client tries to deserialize payload
from JSON (Response::readEntity to be precise).
Best Regards,
Andriy Redko
> CXF metrics - No FaultMode in Exchange for response timeout during reception
> of payload
> ---
>
> Key: CXF-8132
> URL: https://issues.apache.org/jira/browse/CXF-8132
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.1.18, 3.3.3
>Reporter: Emile de Weerd
>Assignee: Andriy Redko
>Priority: Major
> Attachments: cxf-metrics-context-response-timeout-issue.tar.xz
>
>
> While using the CXF metrics feature with a CXF REST client, in some error
> case there is not FaultMode inside the Exchange object passed to the
> MetricsContext#stop method. The use case is when the response body
> transmission is interrupted in the middle of the transfer.
> I wrote a unit test that allows to clearly reproduce. It is failing. The Unit
> test prints out stacktraces whenever start or stop are called from the
> MetricsContext.
> *incompleteResponse_stopCalledOnceWithFaultObjectInExchange*
> [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest -
> MetricsContext#stop called 1 times
> [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called
> with time = 14901568 ns, inSize = -1, outSize = 0, exchange that contains a
> FaultMode = false; callad at:
> [...]
> at
> org.apache.cxf.metrics.MetricsContext$$EnhancerByMockitoWithCGLIB$$1997d2d2.stop()
> at org.apache.cxf.metrics.ExchangeMetrics.stop(ExchangeMetrics.java:75)
> at
> org.apache.cxf.metrics.interceptors.AbstractMetricsInterceptor.stop(AbstractMetricsInterceptor.java:215)
> at
> org.apache.cxf.metrics.interceptors.MetricsMessageInPostInvokeInterceptor.handleMessage(MetricsMessageInPostInvokeInterceptor.java:34)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.jaxrs.client.ClientMessageObserver.onMessage(ClientMessageObserver.java:56)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1693)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1570)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1371)
> at
> org.apache.cxf.io.AbstractWrappedOutputStream.close(AbstractWrappedOutputStream.java:77)
> at
> org.apache.cxf.metrics.interceptors.CountingOutputStream.close(CountingOutputStream.java:47)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:671)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain(AbstractClient.java:709)
> at
> org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:887)
> at
> org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:335)
> at com.sun.proxy.$Proxy22.getBook(Unknown Source)
> at
> cxf.reproducers.CxfMetricsIssueReproducerTest.incompleteResponse_stopCalledOnceWithFaultObjectInExchange(CxfMetricsIssueReproducerTest.java:171)
> [...]
> I am not sure the test case makes sense, maybe that is the first part to
> review.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CXF-8132) CXF metrics - No FaultMode in Exchange for response timeout during reception of payload
[
https://issues.apache.org/jira/browse/CXF-8132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953289#comment-16953289
]
Andriy Redko edited comment on CXF-8132 at 10/17/19 1:02 AM:
-
Hi [~mederel],
I don't think that the test represents the valid use case to be honest. First
of all, the transmission is not interrupted, the mock is configured to send
only part of the response:
{code:java}
httpServer.when(request().withPath("/books/10").withHeader("Content-Type",
MediaType.APPLICATION_JSON))
.error(HttpError.error().withDropConnection(false)
.withResponseBytes(ArrayUtils.subarray(normalAnswerBytes, 0,
normalAnswerBytes.length - 15)));
{code}
Secondly, the client receives the HTTP/200 from server and this is where the
MetricsContext::stop() is called: exactly when the server replies. So from my
perspective, the CXF does proper thing. The fault should not be set in the
exchange since it happens only when client tries to deserialize payload from
JSON (Response::readEntity to be precise).
Best Regards,
Andriy Redko
was (Author: reta):
Hi [~mederel],
I don't think that the test represents the valid use case to be honest. First
of all, the transmission is not interrupted, the mock is configured to send
only part of the response:
{code:java}
httpServer.when(request().withPath("/books/10").withHeader("Content-Type",
MediaType.APPLICATION_JSON))
.error(HttpError.error().withDropConnection(false)
.withResponseBytes(ArrayUtils.subarray(normalAnswerBytes, 0,
normalAnswerBytes.length - 15)));
{code}
Secondly, the client receives the HTTP/200 from server and this is where the
MetricsContext::stop() is called: exactly when the server replies, but . So
from my perspective, the CXF does proper thing. The fault should not be set in
the exchange since it happens only when client tries to deserialize payload
from JSON (Response::readEntity to be precise).
Best Regards,
Andriy Redko
> CXF metrics - No FaultMode in Exchange for response timeout during reception
> of payload
> ---
>
> Key: CXF-8132
> URL: https://issues.apache.org/jira/browse/CXF-8132
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.1.18, 3.3.3
>Reporter: Emile de Weerd
>Assignee: Andriy Redko
>Priority: Major
> Attachments: cxf-metrics-context-response-timeout-issue.tar.xz
>
>
> While using the CXF metrics feature with a CXF REST client, in some error
> case there is not FaultMode inside the Exchange object passed to the
> MetricsContext#stop method. The use case is when the response body
> transmission is interrupted in the middle of the transfer.
> I wrote a unit test that allows to clearly reproduce. It is failing. The Unit
> test prints out stacktraces whenever start or stop are called from the
> MetricsContext.
> *incompleteResponse_stopCalledOnceWithFaultObjectInExchange*
> [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest -
> MetricsContext#stop called 1 times
> [main] INFO cxf.reproducers.CxfMetricsIssueReproducerTest - - stop called
> with time = 14901568 ns, inSize = -1, outSize = 0, exchange that contains a
> FaultMode = false; callad at:
> [...]
> at
> org.apache.cxf.metrics.MetricsContext$$EnhancerByMockitoWithCGLIB$$1997d2d2.stop()
> at org.apache.cxf.metrics.ExchangeMetrics.stop(ExchangeMetrics.java:75)
> at
> org.apache.cxf.metrics.interceptors.AbstractMetricsInterceptor.stop(AbstractMetricsInterceptor.java:215)
> at
> org.apache.cxf.metrics.interceptors.MetricsMessageInPostInvokeInterceptor.handleMessage(MetricsMessageInPostInvokeInterceptor.java:34)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.jaxrs.client.ClientMessageObserver.onMessage(ClientMessageObserver.java:56)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1693)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1570)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1371)
> at
> org.apache.cxf.io.AbstractWrappedOutputStream.close(AbstractWrappedOutputStream.java:77)
> at
> org.apache.cxf.metrics.interceptors.CountingOutputStream.close(CountingOutputStream.java:47)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:671)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(Phase
[jira] [Updated] (CXF-7996) Jakarta EE TCKs and compatibility
[
https://issues.apache.org/jira/browse/CXF-7996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-7996:
--
Description:
Mail thread:
[https://mail-archives.apache.org/mod_mbox/cxf-dev/201901.mbox/%3C6edd1da6-d651-]
e2a3-8092-59bdc7a54...@apache.org%3E
Jakarta EE TCK: [https://projects.eclipse.org/proposals/eclipse-jakarta-ee-tck]
Github Repo: [https://github.com/eclipse-ee4j/jakartaee-tck]
Latest updates from [jakarta.ee-spec] TCK information, June 2019, the excerpts:
* {color:#00}We have summed up some information about how the TCK can be
built (or {color}
{color:#00}grabbed pre-built), configured, and run [1].{color}
* {color:#00}This is assumed to be run against a Glassfish with the latest
API {color}
{color:#00}integrated (replacing the original API in the Glassfish).{color}
* {color:#00}We have created a recording of a presentation of the Jenkins
jobs that {color}
{color:#00}manage all that [2].{color}
* {color:#00}We have created 3 Jenkins files for pipeline job (as an
example for {color}
{color:#00}JSON-B TCK) to a) properly set the ts.jte configuration file,
b) to grab {color}
{color:#00}the API artifact built by a Jenkins build job and integrate it
to a {color}
{color:#00}Glassfish and c) to grab the pre-built TCK bundle from Eclipse
Download, {color}
{color:#00}grab the configured ts.jte file, grab the Glassfish with new
API {color}
{color:#00}integrated, and run the TCK [3].{color}
{color:#00}For the complete information, please allow me to mention the
list of the {color}
{color:#00}TCK tasks needed to be done before the Jakarta EE release can
be {color}
{color:#00}finished [4].{color}
{color:#00}The [5] is the example how to run Jakarta EE TCKs with
Tomcat.{color}
{color:#00}{color:#00}The{color} [6] is the official list of the
instructions.{color}
{color:#00}[1]
{color}+[https://wiki.eclipse.org/TCK:Build_From_Jakarta_EE_TCK_Repo_And_Run]+
{color:#00}[2] {color}+[https://youtu.be/nnD1KMvh0to]+
{color:#00}[3] {color}
+[https://wiki.eclipse.org/TCK:Build_From_Jakarta_EE_TCK_Repo_And_Run#Jenkins_Pipelines]+
{color:#00}[4] {color}+[https://github.com/orgs/eclipse-ee4j/projects/14]+
[5] [https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs]
[6]
+[https://github.com/eclipse-ee4j/jakartaee-tck/wiki/Instructions-for-building-and-running-JakartaEE-TCK-bundle]+
was:
Mail thread:
[https://mail-archives.apache.org/mod_mbox/cxf-dev/201901.mbox/%3C6edd1da6-d651-]
e2a3-8092-59bdc7a54...@apache.org%3E
Jakarta EE TCK: [https://projects.eclipse.org/proposals/eclipse-jakarta-ee-tck]
Github Repo: [https://github.com/eclipse-ee4j/jakartaee-tck]
Latest updates from [jakarta.ee-spec] TCK information, June 2019, the excerpts:
* {color:#00}We have summed up some information about how the TCK can be
built (or {color}
{color:#00}grabbed pre-built), configured, and run [1].{color}
* {color:#00}This is assumed to be run against a Glassfish with the latest
API {color}
{color:#00}integrated (replacing the original API in the Glassfish).{color}
* {color:#00}We have created a recording of a presentation of the Jenkins
jobs that {color}
{color:#00}manage all that [2].{color}
* {color:#00}We have created 3 Jenkins files for pipeline job (as an
example for {color}
{color:#00}JSON-B TCK) to a) properly set the ts.jte configuration file, b)
to grab {color}
{color:#00}the API artifact built by a Jenkins build job and integrate it
to a {color}
{color:#00}Glassfish and c) to grab the pre-built TCK bundle from Eclipse
Download, {color}
{color:#00}grab the configured ts.jte file, grab the Glassfish with new API
{color}
{color:#00}integrated, and run the TCK [3].{color}
{color:#00}For the complete information, please allow me to mention the
list of the {color}
{color:#00}TCK tasks needed to be done before the Jakarta EE release can be
{color}
{color:#00}finished [4].{color}
{color:#00}[1]
{color}+[https://wiki.eclipse.org/TCK:Build_From_Jakarta_EE_TCK_Repo_And_Run]+
{color:#00}[2] {color}+[https://youtu.be/nnD1KMvh0to]+
{color:#00}[3] {color}
+[https://wiki.eclipse.org/TCK:Build_From_Jakarta_EE_TCK_Repo_And_Run#Jenkins_Pipelines]+
{color:#00}[4] {color}+[https://github.com/orgs/eclipse-ee4j/projects/14]+
> Jakarta EE TCKs and compatibility
> -
>
> Key: CXF-7996
> URL: https://issues.apache.org/jira/browse/CXF-7996
> Project: CXF
> Issue Type: Task
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
>
> Mail thread:
> [https://mail-archives.apache.org/mod_mbox/cxf-dev/201901.mbox/%3C6edd1da6-d651-]
> e2a3-8092-59bdc7a54...@apache.org%3E
> Jakarta EE TCK:
> [https
