My interpretation is that it is not valid. What CXF (and Liberty) does in that case is invokes the remote resource (which will wait 30 seconds and then return some entity) which succeeds - but then the response from the remote resource is trumped by the noContent that the filter aborted with. IIUC, this occurs because CXF has executed the filter method and then called the remote resource, but 10 seconds in, the timer fires and aborts the request - this is not immediate, so CXF puts the abort on the Message object, then checks the Message object after it gets a response from the server (20 seconds later) - it sees the aborted request and returns that to the user rather than the good response.
If users want to limit the request time, the can use the connectTimeout and readTimeout methods on the ClientBuilder - the downside is that there is no "overall timeout" like you would get with the client filter approach (i.e. if you wanted to ensure that the complete request/response completed in 10 seconds, you would have to do something like set the connect timeout to 5 and the read timeout to 5). If this is too limiting, I would suggest we investigate an "overall timeout" method rather than aborting after the filter method has executed.
Another possible alternative could be to use an async client method and then specify a 10 seconds timeout in the Future.get(...) method.
Thanks,
Andy
