Thanks, I may need to ask for help, indeed :D
RMB> Le ven. 7 juin 2019 à 20:28, Andriy Redko <[email protected]> a écrit : RMB> I didn't check the "pure" server flow, but I suspect it could be impacted as well. For the last few weeks I RMB> was trying to configure Jakartee EE TCK to run against CXF (it is not very straightforward, but I am slowly RMB> getting somewhere), so we could actually catch such corner (and not only) cases. I will create a ticket RMB> shortly so we won't forget about this issue. Thanks! RMB> If it helps: tomee probably has a setup IIRC, it is a particular integration but runtime is the same so can help. RMB> Getting in touch with pmc can surely give you some pointers at least. RMB> Best Regards, RMB> Andriy Redko 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 RMB> AR>>> Hi Romain, RMB> 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): RMB> AR>>> [INFO] RequestHandlerClass from context returned RMB> com.github.tomakehurst.wiremock.http.AdminRequestHandler. Normalized mapped under returned 'null' RMB> AR>>> [ERROR] Tests run: 145, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 90.181 s <<< FAILURE! - in TestSuitealized mapped under returned 'null' RMB> AR>>> [ERROR] RMB> testAsyncInvocationInterceptorProvider(org.eclipse.microprofile.rest.client.tck.asynctests.AsyncMethodTest) Time elapsed: 0.103 s <<< FAILURE! RMB> AR>>> java.lang.AssertionError: expected [80] but found [null] RMB> AR>>> at RMB> AR>>> RMB> org.eclipse.microprofile.rest.client.tck.asynctests.AsyncMethodTest.testAsyncInvocationInterceptorProvider(AsyncMethodTest.java:235) RMB> AR>>> [INFO] RMB> AR>>> [INFO] Results: RMB> AR>>> [INFO] RMB> AR>>> [ERROR] Failures: RMB> AR>>> [ERROR] AsyncMethodTest>Arquillian.run:138->testAsyncInvocationInterceptorProvider:235 expected [80] but found [null] RMB> AR>>> [INFO] RMB> AR>>> [ERROR] Tests run: 145, Failures: 1, Errors: 0, Skipped: 1 RMB> AR>>> [INFO] RMB> AR>>> Yes, you are right, the test is non-deterministic. Trying to understand what is going on, may take some time. RMB> AR>>> Thanks for noticing it. RMB> AR>>> Best Regards, RMB> AR>>> Andriy Redko RMB> RMB>>>> Hi Andriy, RMB> RMB>>>> Result is random but it is RMB> RMB>>>> org.eclipse.microprofile.rest.client.tck.asynctests.AsyncMethodTest.testAsyncInvocationInterceptorProvider RMB> RMB>>>> Le dim. 2 juin 2019 à 19:12, Andriy Redko <[email protected]> a écrit : RMB> RMB>>>> Hi Romain, RMB> RMB>>>> Yes, the async flows are difficult to test, which test cases for MP rest client are RMB> RMB>>>> intermittently failing for you? I would be able to take a look. Thanks. RMB> RMB>>>> Best Regards, RMB> 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>
