Starting with https://issues.apache.org/jira/browse/CXF-8054 :)
RMB> Well, sadly it is the same as soon as a client can be embed in a server (MP is about that only case AFAIK) for the exact same point. RMB> In other words the question is: does the code impacts the call or a system more related to the app than the HTTP call itself. RMB> Client or server is not that important here and I think we have the issue both sides, no? RMB> Romain Manni-Bucau RMB> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book RMB> Le ven. 7 juin 2019 à 18:10, Andriy Redko <[email protected]> a écrit : RMB> Hi Romain, RMB> Yes, there are things which worry me as well, but we are talking about client here, not the server. When RMB> response is received, it is there, and if client disconnects, should not impact server or status code anyhow. RMB> However, the processing chain on the client side may not be completed, and probably in some cases client may RMB> expect a slightly different response ... For the note, MP Rest Client TCK does not use CXF server(s), it uses RMB> Wiremock. RMB> Best Regards, RMB> 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> RMB>>>> Hi everyone, RMB> RMB>>>> I just realize - thanks for failling test on jenkins, that part of the test RMB> RMB>>>> suite is not deterministic. RMB> RMB>>>> It mainly affects async calls. I found some opentracing ones - fixed by RMB> RMB>>>> https://github.com/apache/cxf/pull/561/commits/23cbbb9db73a74913fd4294f805032f923ffcf09 RMB> RMB>>>> - RMB> RMB>>>> and there are some in MP rest client TCK (async interceptor provider). RMB> RMB>>>> I didn't dig deep into the root cause but I suspect we ack the client RMB> RMB>>>> before the full chain is processed on the server side. RMB> RMB>>>> Does it ring any bell to anyone? RMB> RMB>>>> Romain Manni-Bucau RMB> RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog RMB> RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog RMB> RMB>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | RMB> RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book RMB> RMB>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
