I'm trying to capture/decipher the exceptions being thrown in a SonicConnect web service client under the conditions which occur freuqently with web service interactions:
The main interaction set includes:
I have a fault handler process defined on my SonicConnect client process. Trapping these cases and deciphering them based on the SonicESB.Fault.xxxx headers and message parts is what I need to do in order to determine whether to resubmit or just handle the error response and perform some other processing or termination.
How can I manipulate the timeout value associated with the outbound SonicConnnect client request? I want to make it wait a short amount of time so I can determine what the timeout case fault looks like. It is set on the default 30 seconds but I have a need to shorten this timeout and over-ride the amount of time I wait on my request.
Thanks.
Using a SonicConnect web service client - is there any way to control the HTTP connect and read timeout values during runtime?
CXF conduit level configuration should work. Please check out the ConnectionTimeout and ReceiveTimeout attributes.
http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html
William. Thanks for that. This may not control the properties at runtime, but it does look like this will provide spring.xml configuration file control over the connect and read timeouts for a SonicConnect web service client.
Hi Chris,
I'm in a simular boat, I need to have our sonicConnect retry the client RESTful connection quite a few times.
I was looking for the equivalent X-HTTP-Retries parameter in the connect service but I can't find it.I was going to try just adding the X-HTTP options to the JMS headers before executing the sonicConnect call.
Is the solution you found/implemented of this nature?
I would be very appreciative if you could share this bit of knowledge.
Thank you,
Tony.
Grant,
There are few instances where I need to control the SonicConnect client for retrying requests which fail. Take a look at some of the suggestions provided to another thread I started regarding SonicConnect and Retry Best Practices here:
http://communities.progress.com/pcom/message/136927#136927
A post by Kai discusses element blocks that can be added to the spring.xml config file to control some retry parameters right there in the client (number of retries and timeout between, etc.).
Hope that helps some.
Chris