You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Gaurav Chandna <ga...@gmail.com> on 2013/08/16 13:27:48 UTC

Webservice Client Receive Timeout options - HttpClientPolicy setReceiveTimeout VS Interceptor Message ReceiveTimeout

I am able to set webservice client's receive timeout at web-operation level
rather than webservice level in following 2 ways:
 

*Option1: HTTP POLICY*
sample code:

CustomerService service = getService(); 
        long t = System.currentTimeMillis(); 
        System.out.println("Start time-->" + t); 
        try { 
            HTTPClientPolicy policy = new HTTPClientPolicy(); 
            policy.setReceiveTimeout(3000); 
        
((BindingProvider)service).getRequestContext().put("*thread.local.request.context"*,"true"); 

((BindingProvider)service).getRequestContext().put(HTTPClientPolicy.class.getName(), 
policy); 

*Option 2: Interceptor Level- Message Object setting*
Sample Code:

public class OutTimeoutInterceptor extends 
AbstractPhaseInterceptor<Message> { 
    private int receiveTimeout; 
    public OutTimeoutInterceptor() { 
        *super(Phase.PREPARE_SEND); *    } 
    @Override 
    public void handleMessage(Message message) throws Fault { 
        if("{ 
http://customerservice.example.com/}CustomerServiceServiceSoapBinding".equals(message.getExchange().getBindingOperationInfo().getBinding().getName().toString())) 
{ 
           *message.put(Message.RECEIVE_TIMEOUT, 2000); *        } 
    } 



Question: Which is the better option from above to use from performance and
multi threaded perspective? Our application invloves huge multi threading



--
View this message in context: http://cxf.547215.n5.nabble.com/Webservice-Client-Receive-Timeout-options-HttpClientPolicy-setReceiveTimeout-VS-Interceptor-Message-t-tp5732557.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Webservice Client Receive Timeout options - HttpClientPolicy setReceiveTimeout VS Interceptor Message ReceiveTimeout

Posted by Daniel Kulp <dk...@apache.org>.
If that's the ONLY use of the request context, I would definitely flip to option #2.  Using a thread local request context would consume a bit more memory since there is extra stuff to store per thread, a bit of extra setup, etc…     However, if you need the thread local context for other contextual things, then option 1 is likely a bit better as you'd have already hit all that setup cost.

Dan


On Aug 16, 2013, at 7:27 AM, Gaurav Chandna <ga...@gmail.com> wrote:

> I am able to set webservice client's receive timeout at web-operation level
> rather than webservice level in following 2 ways:
> 
> 
> *Option1: HTTP POLICY*
> sample code:
> 
> CustomerService service = getService(); 
>        long t = System.currentTimeMillis(); 
>        System.out.println("Start time-->" + t); 
>        try { 
>            HTTPClientPolicy policy = new HTTPClientPolicy(); 
>            policy.setReceiveTimeout(3000); 
> 
> ((BindingProvider)service).getRequestContext().put("*thread.local.request.context"*,"true"); 
> 
> ((BindingProvider)service).getRequestContext().put(HTTPClientPolicy.class.getName(), 
> policy); 
> 
> *Option 2: Interceptor Level- Message Object setting*
> Sample Code:
> 
> public class OutTimeoutInterceptor extends 
> AbstractPhaseInterceptor<Message> { 
>    private int receiveTimeout; 
>    public OutTimeoutInterceptor() { 
>        *super(Phase.PREPARE_SEND); *    } 
>    @Override 
>    public void handleMessage(Message message) throws Fault { 
>        if("{ 
> http://customerservice.example.com/}CustomerServiceServiceSoapBinding".equals(message.getExchange().getBindingOperationInfo().getBinding().getName().toString())) 
> { 
>           *message.put(Message.RECEIVE_TIMEOUT, 2000); *        } 
>    } 
> 
> 
> 
> Question: Which is the better option from above to use from performance and
> multi threaded perspective? Our application invloves huge multi threading
> 
> 
> 
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Webservice-Client-Receive-Timeout-options-HttpClientPolicy-setReceiveTimeout-VS-Interceptor-Message-t-tp5732557.html
> Sent from the cxf-user mailing list archive at Nabble.com.

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Re: Webservice Client Receive Timeout options - HttpClientPolicy setReceiveTimeout VS Interceptor Message ReceiveTimeout

Posted by apanwar <ap...@sapient.com>.
Hi Daniel,

We used option#2 for the implementation of operation level timeouts at
client side.

When we introduced this, we saw that the middleware (TIBCO) started failing
to process the requests on the peak load and there are a lot of 503 errors.

If we do the same performance test without this configuration and keep the
timeout generic at the http conduit level then there is no impact on
middleware.

Is there any king of such issue in operation#2 which points towards the
problem we are facing?

Regards,
Amit



--
View this message in context: http://cxf.547215.n5.nabble.com/Webservice-Client-Receive-Timeout-options-HttpClientPolicy-setReceiveTimeout-VS-Interceptor-Message-t-tp5732557p5733315.html
Sent from the cxf-user mailing list archive at Nabble.com.