Le ven. 7 juin 2019 à 20:28, Andriy Redko <[email protected]> a écrit :
> I didn't check the "pure" server flow, but I suspect it could be impacted > as well. For the last few weeks I > was trying to configure Jakartee EE TCK to run against CXF (it is not very > straightforward, but I am slowly > getting somewhere), so we could actually catch such corner (and not only) > cases. I will create a ticket > shortly so we won't forget about this issue. Thanks! > If it helps: tomee probably has a setup IIRC, it is a particular integration but runtime is the same so can help. Getting in touch with pmc can surely give you some pointers at least. > Best Regards, > 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 > > > 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 > > > > > > > > > >
