[jira] [Commented] (CXF-7644) TCK/CTS: JAX-RS async client requests should invoke interceptor chain on separate thread

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (CXF-7644) TCK/CTS: JAX-RS async client requests should invoke interceptor chain on separate thread

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/CXF-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363148#comment-16363148 ]

Sergey Beryozkin commented on CXF-7644:
---------------------------------------

Hi Andy

There have been many cases where TCK tests have misinterpreted the spec or API.

One could say the async call implies the client thread is not blocked waiting for the response, the requirement that even the outbound client interceptors must run on the separate thread seems to be based around the RI implementation specifics.

Might make sense investigating it further. In general, challenging the TCK tests is not always a bad idea. The fact the spec or API is silent about this detail can be sufficient to challenge; the alternative is probably a major rewrite of the way WebClient is implemented

> TCK/CTS: JAX-RS async client requests should invoke interceptor chain on separate thread
> ----------------------------------------------------------------------------------------
>
>                 Key: CXF-7644
>                 URL: https://issues.apache.org/jira/browse/CXF-7644
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.2.2
>            Reporter: Andy McCright
>            Priority: Major
>
> The JAX-RS 2.1 TCK is using ClientRequestFilters to verify that it is on a separate thread than the main client thread.  Although it is not specific in the spec that providers like filters must be invoked on a new thread, I believe this line from the spec (section 8.4) is what they base this test on:
> _Note that in this example, the call to get after calling async returns immediately without blocking the caller’s thread._
>  
> Currently, we call WebClient.doInvokeAsync(...) which calls prepareAsyncClient(...) which calls doRunInterceptorChain(...) - all on the main client thread. As a result the filters on the outbound chain get executed on the same thread which breaks the test.
> I wrote a simpler test case that similarly breaks, but could use some help with how to implement the fix:
>  
>     public static class ThreadCheckFilter implements ClientRequestFilter {
>         @Override
>         public void filter(ClientRequestContext context) throws IOException {
>             final Thread currentThread = Thread.currentThread();
>             context.abortWith(Response.ok(currentThread.getName())
>                                        .header("ThreadID", currentThread.getId())
>                                        .build());
>         }
>     }
>  
>     @Test
>     public void testClientRequestFilterRunsOnSepaarateThreadWhenInvokedAsynchronously() throws Exception {
>         final Thread currentThread = Thread.currentThread();
>         Client client = ClientBuilder.newClient();
>         client.register(ThreadCheckFilter.class);
>         WebTarget target = client.target("http://localhost:8080/notReal");
>         AsyncInvoker invoker = target.request().async();
>         Future<Response> future = invoker.get();
>         Response response = future.get();
>         assertNotEquals(currentThread.getName(), response.readEntity(String.class));
>         assertNotEquals(currentThread.getId(), Long.parseLong(response.getHeaderString("ThreadID")));
>     }



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)