Feature request: adjustable socket timeouts
kkieffer opened this issue · 9 comments
I would like to be able to set the timeouts for connect/read/write as the defaults are kinda long. I think this is as simple as, after creating the socket calling:
socket.setReadTimeout(value: timeout)
socket.setWriteTimeout(value: timeout)
and replacing the socket.connect() method with the overloaded one that takes a timeout.
The timeout values could be stored in the ConnectionConfiguration struct.
It looks like the default timeout is "never". Is this what you are seeing?
Under what circumstances would the connect, read, and write timeouts be different? In other words, do you see a need for 3 config properties for the connect, read, and write cases? Or would a single "socket timeout" property be sufficient?
I think one timeout value would suffice for all. The default does eventually return with a socket error, seems like maybe a minute or so.
OK thanks. Working on it...
Feel free to try this out (branch pitfield/socketTimeout). Thanks!
Working on connect. I get a SOCKET_ERR_CONNECT_TIMEOUT after my timeout expires.
If I establish a good connection to Postgres, then disable my internet connection, on my next database call - I don't get a return for 30 seconds. Then I get the error "errSSLClosedAbort".
I suspect the socket read is returning EAGAIN, which causes the SSL library to give error errSSLWouldBlock, and it retries.
Anyway, this is okay for me. It was the connect really taking forever.
Thanks for trying this. I suspect you are correct about the SSL layer consuming the timeout.
By the way, how are you simulating (or otherwise triggering) the connect timeout?
The test DB has to be on a different subnet - then break the connection between the iOS device's network and the DB's network. If you just turn off the device's Wi-fi I believe you just get a "unknown host" since it has no IP/gateway assigned. In my case I turned off my router's WAN connection, since the DB was elsewhere on the internet.
Commit c6ac055 should fix the timeout for socket reads. Note that the new configuration property is a socket timeout, not an operation timeout. Upon any error performing an operation, PostgresClientKit tries to determine whether the connection is salvageable (by performing a so-called "sync request"). So, with a socket timeout of 4 (for example), if the network goes down, a call to the PostgresClientKit API may not return for up to 8 seconds: 4 seconds for the original request, then another 4 seconds for the follow-up sync request.
Available in v 1.1.0.