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. 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. Client or server is not that important here and I think we have the issue both sides, no?
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 7 juin 2019 à 18:10, Andriy Redko <[email protected]> a écrit : > 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 > > > > > > > >
