Why OSB Read Just Doesn't Time Out

Business Service call may take much longer than the timeout specified for that service.

OSB business services have connect and read timeouts to prevent indefinite waiting for the backend service.

Just set it to, for instance, 15 seconds and the call will never last longer than that! … Right?

Nope. It can take forever.

First, let’s realize what “read timeout” really means.

Read timeout is not triggered when the request is not completed 15 seconds after successful connect. It is triggered when there are no new data came for 15 seconds.

The data are coming in packets, usually of 1.5K size, but they could also be smaller if the sending side or a router decides so. The server may even send a 3K response as 3000 packets of 1 byte each, 10 seconds apart. As long as each packet is coming 15 seconds or less after the previous one, the read timeout will not happen.

The overall request may take many times the read timeout value.

But wait, there is more!

What about connect timeout? Can it take longer than we configured?

Yes it can. Not in plain HTTP though, but in HTTPS.

The code that is responsible for establishing the HTTPS connection is complicated and contains retry logic. When the key exchange breaks at particular moment, this code re-initiates the connection. It does it a few times before eventually failing, and all this time the request is waiting.

(Interesting also that the key exchange is controlled by read timeout, while technically the key exchange is a part of connect sequence. Oh well.)

Another way OSB may defy the set timeout is by calling a HTTPS service via a HTTP proxy. OSB then uses CONNECT method, and shall something go wrong with the proxy, the request hangs forever.

Beware.