quick hack to prevent indefinite buildup of closenotify routines

[whyrusleeping]

Until we get closeNotify fixed, this will help prevent these goroutines from hanging forever and building up in memory.

License: MIT
Signed-off-by: Jeromy jeromyj@gmail.com

[ghost]

Will this properly kill a connection that is legitimately still open? (It's good if it does, just wondering if it'd still leak, just the other way around.)

[whyrusleeping]

it will kill an active connection, yes. The only good way to fix this is to fix close notify :/

[rht]

Actually this isn't a 'quick hack'. The timeout should exist but can be made longer when closenotifier is fixed.

There is only one test for nonexisting hash so far, https://github.com/ipfs/go-ipfs/blob/792da9d87587e28d65b98a28fa4cc2d20388ccca/test/sharness/t0220-bitswap.sh#L15, and even here the timeout is explicitly specified.
(if the daemon is up, then this hash will stay in the wantlist indefinitely even after the timeout)

Also there should be a way to check for active connections, e.g. http.StateActive for ConnState (in fact, this has been used to remedy the closenotifier stuff).

[jbenet]

what if a file is legitimately big enough + over a low bw conn to require 30min to stream? again, this needs to take into account the rate + progress. a timeout like this is ok when there havent been any bytes through (or too few)

[whyrusleeping]

closing in favor of #2032

[rht]

I think a timeout is still required for core.Resolve of a nonexistent hash.

[jbenet]

@rht how do you distinguish (a) a nonexistent hash, (b) a hash normally available, just not now, (c) a hash hosted by a node very far away (latencies above 10s).

i think the "what to do" really depends on use case.

• someone "wanting to download the thing" and not minding how long it takes would leave an app open like a bittorrent client.
• someone building a webapp would want to know immediately if the thing isn't resolving.
  i'm strictly opposed to "always must timeout" because sometimes a user still wants to try resolving long term. (think of a torrent with no other users sitting lonely in the app, but eventually another user joins). but i do agree we need to set client-side timeouts by default more often and make setting infinite timeout a more explicit thing.

i also think that making sure all hashes being resolved have a context tied to the client properly will solve most problems: the issue is that a client issues "get X" and disappears. the context should be cancelled when the client disappears. it's like ssh <host> myprogram, myprogram will run until i disconnect. and i can also specify nohup.