JAX-WS client ASYNC service invocation using WLS 10.3.3

I am writing an integration webservice which will consume various webservices from a couple different backend systems. I want to be able to parallelize non-dependent service calls and be able to cancel requests that take too long (since I have an SLA to meet).

to aid in parallel backend calls, I am using the ASYNC client apis (generated by wsimport using the client-side jax-ws binding alteration files)

the issue I am having is that when I try to cancel a request, the Response<> appropriately marks the request as canceled, however the actual request is not really canceled. apparently some part of the JAX-WS runtime actually submits a com.sun.xml.ws.api.pipe.Fiber to the run queue which is what actually does the request. the cancel on the Result<> does not prevent these PIPEs from running on the queue and making the request.

has anyone run into this issue or a similar issue before?

My code looks like this:

List<Response<QuerySubscriberResponse>> resps = new ArrayList<Response<QuerySubscriberResponse>>();

for (int i = 0; i < 10; i++) {
    resps.add(FPPort.querySubscriberAsync(req));
}

for (int i = 0; i < 10; i++) {
    logger.info("Waiting for " + i);
    try {
        QuerySubscriberResponse re = resps.get(i).get(1,
                TimeUnit.SECONDS);   // execution time for this request is 15 seconds, so we should always get a TimeoutException
        logger.info("Got: "
                + new Marshaller().marshalDocumentToString(re));
    } catch (TimeoutException e) {
        logger.err开发者_JAVA技巧or(e);
        logger.error("Cancelled: " + resps.get(i).cancel(true));

        try {
            logger.info("Waiting for my timed out thing to finish -- technically I've canceled it");
            QuerySubscriberResponse re = resps.get(i).get(); // this causes a CancelledExceptio as we would expect
            logger.info("Finished waiting for the canceled req");
        } catch (Exception e1) {
            e1.printStackTrace();
        }


    } catch (Exception e) {
        logger.error(e);
    } finally {
        logger.info("");
        logger.info("");
    }
}  

I would expect that all of these requests would end up being cancelled, however in reality they all continue to execute and only return when the backend finally decides to send us a response.

as it turns out this was indeed a bug in the jax-ws implementation. Oracle has issued a Patch (RHEL) against wls 10.3.3 to address this issue.