1

We've reproduced this one in Test, so I feel good about asking this question - not that I understand it or anything. ;-)

WebMethods is connecting to an IIS Web Service (I'm the IIS guy, and the WebMethods guy has no answer for me.) IIS is throwing 200 0 1236 errors on most of the calls, though. The cause of that is Timer_MinFileBytesPerSec. WebMethods is happy with the result IIS sends, and doesn't always close the network conversation politely. This is not a problem until we get two calls in flight at the same time. If IIS kills the first convo for MinBytes it will kill all open convos with that IP address, thereby killing the second conversation in passing. WebMethods pukes on that error, and I get called.

Is there any way to force WebMethods to end the network conversation politely?

The convos go like this:

Failed convo:

WebMethods sends SOAP in 2 packets - SOAP + HTTP continuation
IIS sends ACK
15 second processing delay
IIS sends SOAP reply with ACK/PUSH/FINISH flags
WebMethods sends ACK flag
15 second delay
IIS sends Reset flag and conversation dies

Successful convo:

WebMethods sends SOAP in 2 packets - SOAP + HTTP continuation
IIS sends ACK flag
15 second processing delay
IIS sends SOAP reply with ACK/PUSH/FINISH flags
WebMethods sends ACK flag
6 second delay
WebMethods sends ACK/FINISH flag
IIS sends ACK flag
We all go home happy

If I extend the ConnectionWaitTimeout and HeaderWaitTimeout on IIS and contract the MinFileBytesPerSec setting, I can make IIS wait indefinitely for WebMethods to politely send the ACK/FINISH, but it never comes.

Any thoughts?

codepoke
  • 1,272
  • 1
  • 22
  • 40
  • What's this 15 seconds of processing delay? Most web clients, ie. browsers, can't handle that. And are you sending it the Keep-Alive header? – Frank Krueger May 04 '10 at 15:54
  • Good question. I've asked it of the developers several times, and it cannot be worked around. Long wait times function normally for several implementations, so they've made their case. It's the second delay that is the issue - waiting on WebMethods to send their second ACK and add the FINISH. It's all black-box to me. I don't know what they're doing differently on their side when the 6 second ACK/FINISH happens, but it's on the WM side. And no, they're not sending a Keep-Alive header on either successful or unsuccessful convos. – codepoke May 04 '10 at 17:01

1 Answers1

1

This is a flaw in WebMethods 6.5. When the same code was run from WebMethods 8, the problem evaporated.

codepoke
  • 1,272
  • 1
  • 22
  • 40