Timeout passed to a ZnClient is ignored while making the connection via the underlying socket about zinc HOT 4 OPEN

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

from zinc.

@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.

from zinc.

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 :)

from zinc.

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.

from zinc.