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!
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>
