Hi Romain,
Yes, there are things which worry me as well, but we are talking about client
here, not the server. When
response is received, it is there, and if client disconnects, should not impact
server or status code anyhow.
However, the processing chain on the client side may not be completed, and
probably in some cases client may
expect a slightly different response ... For the note, MP Rest Client TCK does
not use CXF server(s), it uses
Wiremock.
Best Regards,
Andriy Redko
RMB> Hi Andriy,
RMB> This is what I suspected and actually it triggers a question: if I have an
interceptor which must work on the
RMB> response, how can it be executed before the response is actually sent?
Typically a 200 can become a 500 because the
RMB> client disconnected or so, so if you don't behave as CXF does today you
can have some wrong data in your interceptors - or filters if you use the spec
directly.
RMB> Personally I think we should use phases (Priorities in jaxrs IIRC) to
support that. In other words, it should be
RMB> possible to execute code after the response was actually sent but
serialization etc happens before the completion happens.
RMB> Does it make any sense?
RMB> Romain
RMB> Le ven. 7 juin 2019 à 17:45, Andriy Redko <[email protected]> a écrit :
RMB> Hi Roman,
RMB> Sorry, took me a bit longer to troubleshoot the test cases but at this
point the picture
RMB> is very clear. So yeah, test in question is not deterministic (flaky, in
other words) due
RMB> to the way CXF handles async flows (in this case, on client side). The
interceptors are
RMB> called in the context of the dedicated work pool. The response completion
is tied to the moment
RMB> the stream is closed, after that the interceptors chain is resumed. Which
essentially
RMB> is the cause why the test may fail from time to time:
RMB> 1) Response is completed, the callback is triggered (worker thread),
completing the CompletableFuture
RMB> 2) The interceptor chain is still ongoing (worker thread)
RMB> 3) The test unblocks (main thread) and proceed with assertions
RMB> 4) Here we come with the timing issue
RMB> It turned out to be very easy to reproduce, however it also seems to be
the issue
RMB> specific to CXF implementation. We could make the test more reliable (but
it would leak
RMB> CXF specifics, either directly or indirectly) or we could delay the
response completion
RMB> till the moment interceptors do actually finish the processing, could be
not trivial change
RMB> though. Do you have any thoughts on that?
RMB> Best Regards,
RMB> Andriy Redko
AR>> Hi Romain,
AR>> Run the test suite probably few dozen times on Windows and Ubuntu boxes,
got it failing a few times on Ubuntu (but no failures on Windows):
AR>> [INFO] RequestHandlerClass from context returned
com.github.tomakehurst.wiremock.http.AdminRequestHandler. Normalized mapped
under returned 'null'
AR>> [ERROR] Tests run: 145, Failures: 1, Errors: 0, Skipped: 1, Time elapsed:
90.181 s <<< FAILURE! - in TestSuitealized mapped under returned 'null'
AR>> [ERROR]
testAsyncInvocationInterceptorProvider(org.eclipse.microprofile.rest.client.tck.asynctests.AsyncMethodTest)
Time elapsed: 0.103 s <<< FAILURE!
AR>> java.lang.AssertionError: expected [80] but found [null]
AR>> at
AR>>
org.eclipse.microprofile.rest.client.tck.asynctests.AsyncMethodTest.testAsyncInvocationInterceptorProvider(AsyncMethodTest.java:235)
AR>> [INFO]
AR>> [INFO] Results:
AR>> [INFO]
AR>> [ERROR] Failures:
AR>> [ERROR]
AsyncMethodTest>Arquillian.run:138->testAsyncInvocationInterceptorProvider:235
expected [80] but found [null]
AR>> [INFO]
AR>> [ERROR] Tests run: 145, Failures: 1, Errors: 0, Skipped: 1
AR>> [INFO]
AR>> Yes, you are right, the test is non-deterministic. Trying to understand
what is going on, may take some time.
AR>> Thanks for noticing it.
AR>> Best Regards,
AR>> Andriy Redko
RMB>>> Hi Andriy,
RMB>>> Result is random but it is
RMB>>>
org.eclipse.microprofile.rest.client.tck.asynctests.AsyncMethodTest.testAsyncInvocationInterceptorProvider
RMB>>> Le dim. 2 juin 2019 à 19:12, Andriy Redko <[email protected]> a écrit :
RMB>>> Hi Romain,
RMB>>> Yes, the async flows are difficult to test, which test cases for MP
rest client are
RMB>>> intermittently failing for you? I would be able to take a look. Thanks.
RMB>>> Best Regards,
RMB>>> Andriy Redko
RMB>>>> Hi everyone,
RMB>>>> I just realize - thanks for failling test on jenkins, that part of
the test
RMB>>>> suite is not deterministic.
RMB>>>> It mainly affects async calls. I found some opentracing ones - fixed
by
RMB>>>>
https://github.com/apache/cxf/pull/561/commits/23cbbb9db73a74913fd4294f805032f923ffcf09
RMB>>>> -
RMB>>>> and there are some in MP rest client TCK (async interceptor provider).
RMB>>>> I didn't dig deep into the root cause but I suspect we ack the client
RMB>>>> before the full chain is processed on the server side.
RMB>>>> Does it ring any bell to anyone?
RMB>>>> Romain Manni-Bucau
RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog
RMB>>>> <http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> |
RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
RMB>>>>
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
