Hi All,

Recently we started to receive the following error during a multi soap call service:

[ISC.0077.9998E] Exception → org.apache.axis2.AxisFault: java.net.ConnectException: Connection timed out: connect

This suggested a timeout between request and response in a soap call.

According to documentation you can set a parameter timeout on the pub.client:soapClient interface. However as there are many on this service and again according to documentation you can set a generic timeout value in the extended setting watt.server.SOAP.request.timeout.

After enabling watt.server.SOAP.request.timeout=3 for a 3 second timeout, and restarting the IS, I find I am still getting the same original timeout error (I am sure of the values set and of the restart).

Can anyone advise whether there is something else I need to set to ensure that this delay is observed.

Many Thanks

Hi Lawrence,

which version of wM are you working on?

Please explain what do you mean with multi soap call?
Are invoking several WebServices in sequence?

You can specify the timeout in a variable at the beginning of your service and assign this variable to the timeout input parameter of the soapClient service.

Please try several values to find the correct one.

Additionally check with the partner system if the timeout is occuring on their side already and is only reported to your service.

Regards,
Holger

Hi Holger

Many thanks for your reply.

IS 9.6 corefix 15.

I haven’t implemented a timeout in the service, there are multiple functions/connectors produced from the third party WSDL and multi soap call means that each step from Login through load invokes separate web service operations in sequence.

We use our service to feed a number of varieties of data to the third party. All bar one of the jobs completes normally. One is giving us this issue, and not every time it’s run. It involves a very vigorous activity in requesting third party records, deleting these and then loading new records.

I haven’t yet inquired with the third party if this a timeout on their side handed over to us, although if it is this might be a reason why our implemented global timeout isn’t respected. I can check that thank you.

Thanks again for your input.