[ 
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(<generated>)
>  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)

Reply via email to