[ 
https://issues.apache.org/jira/browse/CXF-8955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Wins updated CXF-8955:
------------------------------
    Description: 
Hi, I am trying to set custom read timeouts for WS operations in an interceptor:
{code:java}
public class CustomReadTimeoutInterceptor extends 
AbstractPhaseInterceptor<Message> {
...
@Override
public void handleMessage(Message message) {
  message.put(Message.RECEIVE_TIMEOUT, timeoutMillis);
}
...{code}
That works well when using the JDK http client, but it does NOT work with the 
hc5 async client.
It looks like requests issued in parallel affect each others timeout settings.

 

Download the attached sample project, which contains a 
CustomReadTimeoutInterceptor and starts two requests in parallel with different 
timeouts (4 and 2 seconds).

Execute both 
{code:java}
mvn
{code}
and
{code:java}
mvn -DuseAsync
{code}
and compare the output. The output of the first will be like
{code:java}
CLIENT[19]: Duration: 2010 millis 
CLIENT[29]: Duration: 4211 millis{code}
(which is as expected) whereas the second - using hc5 async - will result in
{code:java}
CLIENT[29]: Duration: 4269 millis  
CLIENT[19]: Duration: 4012 millis{code}
Now I am wondering if my code is somehow incorrect or if it is cxf's fault...

  was:
Hi, I am trying to set custom read timeouts for WS operations in an interceptor:
{code:java}
public class CustomReadTimeoutInterceptor extends 
AbstractPhaseInterceptor<Message> {
...
@Override
public void handleMessage(Message message) {
  message.put(Message.RECEIVE_TIMEOUT, timeoutMillis);
}
...{code}
That works will when using the JDK http client, but it does NOT work with the 
hc5 async client.
It looks like requests issued in parallel affect each others timeout settings.

 

Download the attached sample project, which contains a 
CustomReadTimeoutInterceptor and starts two requests in parallel with different 
timeouts (4 and 2 seconds).

Execute both 
{code:java}
mvn
{code}
and
{code:java}
mvn -DuseAsync
{code}
and compare the output. The output of the first will be like
{code:java}
CLIENT[19]: Duration: 2010 millis 
CLIENT[29]: Duration: 4211 millis{code}
(which is as expected) whereas the second - using hc5 async - will result in
{code:java}
CLIENT[29]: Duration: 4269 millis  
CLIENT[19]: Duration: 4012 millis{code}
Now I am wondering if my code is somehow incorrect or if it is cxf's fault...


> Custom timeout with Message.RECEIVE_TIMEOUT not working with hc5
> ----------------------------------------------------------------
>
>                 Key: CXF-8955
>                 URL: https://issues.apache.org/jira/browse/CXF-8955
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-WS Runtime
>    Affects Versions: 4.0.3
>         Environment: Fedora 36, Java 17, cxf 4.0.2
>            Reporter: Michael Wins
>            Priority: Major
>         Attachments: cxf_timeout_bug.tar-2.gz
>
>
> Hi, I am trying to set custom read timeouts for WS operations in an 
> interceptor:
> {code:java}
> public class CustomReadTimeoutInterceptor extends 
> AbstractPhaseInterceptor<Message> {
> ...
> @Override
> public void handleMessage(Message message) {
>   message.put(Message.RECEIVE_TIMEOUT, timeoutMillis);
> }
> ...{code}
> That works well when using the JDK http client, but it does NOT work with the 
> hc5 async client.
> It looks like requests issued in parallel affect each others timeout settings.
>  
> Download the attached sample project, which contains a 
> CustomReadTimeoutInterceptor and starts two requests in parallel with 
> different timeouts (4 and 2 seconds).
> Execute both 
> {code:java}
> mvn
> {code}
> and
> {code:java}
> mvn -DuseAsync
> {code}
> and compare the output. The output of the first will be like
> {code:java}
> CLIENT[19]: Duration: 2010 millis 
> CLIENT[29]: Duration: 4211 millis{code}
> (which is as expected) whereas the second - using hc5 async - will result in
> {code:java}
> CLIENT[29]: Duration: 4269 millis  
> CLIENT[19]: Duration: 4012 millis{code}
> Now I am wondering if my code is somehow incorrect or if it is cxf's fault...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to