Timeout passed to a ZnClient is ignored while making the connection via the underlying socket

[akellens]

Suppose the following situation:

• Create a ZnClient
• Pass in an explicit timeout (e.g., 3 seconds)
• Pass in a host/port combination that does not exist

Expected behavior: an error should be thrown after 3 seconds.

What happens: the user has to wait for the (default) timeout of GsSocket; the timeout passed in to the client is ignored.

Reason: the SocketStream does not use the timeout while connecting to the socket created via SocketStreamSocket.

In the code this is reflected in the following extension method

SocketStream>>openConnectionToHost: host port: portNumber timeout: timeout
| socket |
socket :=SocketStreamSocket newTCPSocket.
socket connectTo: host port: portNumber.
^(self on: socket) 
    timeout: timeout; 
    yourself

I compared this with the Pharo implementation, and here the timeout is passed.

[dalehenrich]

Timeout now passed through on connect (glassdb/glass@7ec66c5)

[jbrichau]

@dalehenrich We applied this patch in a 3.1.0.6 extent but I'm getting some weird experimental timings. If we pass 30s to the ZnClient (which is 30000ms passed to the GsSocket timeout parameter), it goes way over 60s. If I set the timeout to 3s, it eventually times out after 8s. For a declared timeout of 5s, it takes over 10s to timeout.

Looking at the code, this is because GSSocket>>connectTo:on:timeoutMs: has a loop where the given timeout value is passed to writeWillNotBlockWithin:, eventually waiting multiple times for the timeout.

I would expect the entire ZnClient connection to timeout after the given value, but now it takes the value multiplied by the length of the addrList variable.

[jbrichau]

Not sure what the right solution for this is. If I understand correctly, each network interface on the machine gets tried with the specified timeout. It does not seem a good idea to wait for timeoutMs / addrList size :)

[jbrichau]

Then again... it seems that's the way curl deals with these situations: http://curl.haxx.se/mail/lib-2014-11/0164.html
Or at least they did.... they apply a different distribution of the timeouts but the overall idea remains to divide the timeouts over the possible addresses.