Problems with watt.net.timeout and web service calls

Hello all,

I am having a continuing problem with Integration Server and Web Service calls. I’ve been required to set the watt.net.timeout due to other issues.

In a scenario where an individual flow service makes 2 consecutive web service calls, if the first call times out, there are issues making the second call. The flow service either waits a long time to make the second call or does not even attempt it.

I’m considering trying to get my organization to upgrade to 8.2.3 to try to address the problem. Has anyone had similar issues? Has anyone had success with an upgrade?

Hi Daniel,
What version are you on now? Is it two distinct web service calls or the same call but you are trying to retry it? Are you catching the timeout error? What do you have you current timeout set for? You shouldn’t have to upgrade the IS service for this, kinda sounds like something else going on.

Mark

What is the current setting value you have in the watt.net.timeout? Is the WS request coming thru the DMZ to internal IS or its a direct hit?

Also there are some other timeout settings along with this that may help…

HTH,
RMG

I’m on Version 8.2.2 now. It is two distinct Web service calls. The second call is supposed to pass the information returned from the first call to the second one.

I am catching the exception with the standard nested SEQUENCE blocks. It is definitely an Integration Server issue and not a firewall/DMZ/etc., issue because I am hosting both Integration Server and the Web Services host (JBoss 5.1) on the same machine. Everything works fine when there are no errors and when the Web Service returns a fault that is of my creation (for example, say I just throw an Exception immediately from the Web Service).

Other timeouts would be great, I tried using watt.server.SOAP.request.timeout without anything of note happening differently.

Thanks for your feedback.

Oh, and I varied my watt.net.timeout setting between 5 and 120 seconds, just trying to get the errors to occur during testing.

Daniel,
Can you give a little diagram of how you have the calls laid out in your flow for example:

Seq(Parent)
Seq(Try)
webservice call 1
webservice call 2
Seq(Catch)
Error handling

Or do you have your service calls embedded in child flow services? And are they wrapped in try/catch?

Very similar to what you have, but two separate try blocks

Seq(Parent)
Seq(Try)
x = webservice call 1
Seq(Catch)
x = FAIL

Seq(Parent)
Seq(Try)
webservice call 2 and send X.
Seq(Catch)
Error handling

Okay two more questions, if call A errors/timeouts what do you want to happen? And how are you initiating this flow service?

By the way, thanks for all your assistance.

What do I want to happen if A times out? I’d like it to be able to be able to have that as the fault returned by the Web Service call. And then I’d like to set a map value so that when I call B I can inform the B web service that A did not successfully complete and should be available for retry.

How did I initiate this flow service? Document trigger. The associated document had data that I passed as parameters to web service A.

Since you are calling out from IS(so IS is the client) you should receive this java.net.SocketTimeoutException: Read timed out, if you’ve cranked down the timeout low enough to cause a timeout. You won’t get a SOAP fault since the client is managing the timeout in this case. On your outbound web service connector within IS just set the “timeout” parameter to like “2” it will immediately throw the error. That will put you in your first catch block so you are going to have to use a global variable in order for it to be visible to your next try/catch block.

Hmm.

You’re obviously right about the Web Service fault. I’m both catching exceptions and looking for faults.

I’ll try the “timeout” parameter, I hadn’t had much luck with it, but if you’ve had success with it then i’ll do a few more experiments. One of my problems hasn’t been an inability to detect the timeoutl but that IS would block on the second call and wouldn’t even try to make it.

Are you using 8.2.2 also? I had someone else tell me at one point that this might have been addressed in 8.2.3?

Daniel,

There is no 8.2.3 for IS yet…what you are referring to exactly is it IS or Broker 823 you meant?

HTH,
RMG

I talked to someone from Global Consulting who said that there was a newer version. I guess I just assumed it would be 8.2.3 based upon the Broker versioning. I haven’t had a lot of luck getting Global Consulting to explain the versioning system and where patches and fix packs fit in. :frowning:

I’m running:
Product webMethods Integration Server
Version 8.2.2.0
Updates None
Build Number 209

No not yet IS823 currently it is IS 822 (Core Fix9 level).

Hi Rmg/Mark,

I have a similar issue where we have a webmethods flow which is actually exposed as a webService to our internal tool, This flow service inturn calls another webService outside of our network.

The internal tool makes a webservice call to the flowservice, the first call is successful but the subsequent calls gets timeout errors. I am not sure how to debug this issue. Do I need to set anything before I could see of any issues?

Kumar,

What is your IS version and what do you see in the logs which service times out?

Please elaborate on your WS calls and assuming this is still in your lower level environment?

HTH,
RMG