• jbenet_
        whyrusleeping that DialPeer (goroutine 24711) is waiting for the other side _or_ ctx timeout. is there another side? and looks like it gets no ctx timeout.
      • pfraze joined the channel
      • whyrusleeping
        jbenet_: there should be another side...
      • inconshreveable joined the channel
      • jbenet: are you not a pumpkin yet?
      • jbenet
        almost -- think the otherside closed prematurely?
      • whyrusleeping
        not sure why it would have. its all on the same computer
      • all the instances are in that log file
      • tperson: i wish such a thing existed...
      • jbenet: the goroutine spawned on line 150 of connection.go in spdystream seems like it could be done a bit better
      • like, the stream could just have a 'close' function that would drain all the buffers for it
      • jbenet
        yeah, lots of things could be better in that pkg. but may be worth not spending much time on it. (unless we find errors)
      • whyrusleeping
        why, you thinking of switching?
      • jbenet
        no, but i dont want to sink too much time into understanding why they did things certain ways.
      • whyrusleeping
        yeah... i guess.
      • i guess since its docker we can just file bug reports, lol
      • jbenet
        yeah, though not sure they're using it much anymore. last commit was 3mo ago.
      • whyrusleeping
        it just worries me that i have 1330 of those goroutines active
      • jbenet
      • test cases do spawn a lot more connections
      • whyrusleeping
        still, thats a rather absurd number
      • especially since they were all hanging for 15 minutes
      • none of them closed out
      • yeah... it really looks like the spdystream randomly drops connections or something
      • the test im running will occasionally get farther before hanging
      • lots of goroutines hanging in DialPeer
      • waiting on <-done
      • jbenet
        sure it's spdystream? sometimes the kernel will drop lots of incoming dials if the listener isn't in `Accept`.
      • (i.e. there's a limited buffer)
      • but if we weren't seeing this before then yeah, it's probably in spdystream. (or my use of it)
      • whyrusleeping
        well... i would most likely see an error if the kernel dropped something like that