Timeouts?

[laurencer]

How does this library handle timeouts? I can't see anywhere to specify them (or whether there is an implicit default). Everything just goes from Connection -> Request -> IO a (or something like that) where neither Connection nor Request have any connection-level concerns (like timeouts).

Haxr depends on it for sending HTTP requests, and appears to be failing with timeouts when used from confluence-sync against a slow Confluence instance (> 5 second request latency).

Is there anything I'm missing in this library, or have I been lead down the wrong path by error messages somewhere in my stack?

[laurencer]

So found the issue. Timeouts are set on the socket itself (not via io-streams).

By using network-socket-options (or alternatively just the plain Network.Socket interface), you can add in a couple of IO actions that set the timeouts.

For example (for the openConnection function).

    s <- socket f Stream defaultProtocol

    let timeoutMicros = 60000000 -- 60 seconds
    setRecvTimeout s timeoutMicros
    setSendTimeout s timeoutMicros

This also needs to be done for openConnectionSSL.

I haven't issued a pull request because I'm not sure how you want to expose access to the Socket or timeouts via the API. Any ideas @afcowie ?

[laurencer]

For an example - see the manual/hardcoded workaround in https://github.com/laurencer/confluence-sync/blob/master/vendor/http-streams/lib/Network/Http/Connection.hs#L179

[istathar]

@laurencer Thanks for digging into this. I actually just fired up IRC to start asking around.

Exposing what was an internal detail to user configuration is a tough one. It's supposed to be in the domain of "just works", but this isn't the first time meddling with the connection code has come up. Timeout is a fairly pervasive concept, and we really ought to support adjusting it.

I'll have a look at a few of the other open issues and see if there's a common enough thread to justify an API smash. bbiab.

AfC