You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 6, 2018. It is now read-only.
Repository navigation
This repository was archived by the owner on Jul 6, 2018. It is now read-only.
agree; i'm writing some code running as http2 client, with current node-v8.7.0 it requires me to call client.destroy() to quit when no other things hold the event loop
vs. http.get( ... ) does not need to worry close the connection.
@c0b I think that's a slightly different issue though because get is one request vs connect which is a whole connection. How does net.connect behave in a similar situation? Also it's better to open issues in the main Node tracker now that http2 is a part of core.
@jasnell I would say this is a broader issue of the client not matching the http client but in terms of how http2.connect works, this seems right to me since it mimics other places where a persistent connection is established (net.connect or tls.connect).
Activity
[-]http2: client should be unref()[/-][+]http2: client should be unref() by default[/+]c0b commentedon Oct 24, 2017
agree; i'm writing some code running as http2 client, with current node-v8.7.0 it requires me to call
client.destroy()to quit when no other things hold the event loopvs. http.get( ... ) does not need to worry close the connection.
apapirovski commentedon Oct 24, 2017
@c0b I think that's a slightly different issue though because
getis one request vsconnectwhich is a whole connection. How doesnet.connectbehave in a similar situation? Also it's better to open issues in the main Node tracker now that http2 is a part of core.jasnell commentedon Oct 24, 2017
Yep, I should actually close out all of the issues here.
The point still stands tho... we should see if there's some reasonable approach we can take here.
apapirovski commentedon Oct 24, 2017
@jasnell I would say this is a broader issue of the client not matching the http client but in terms of how
http2.connectworks, this seems right to me since it mimics other places where a persistent connection is established (net.connectortls.connect).addaleax commentedon Oct 24, 2017
Fun fact, I was actually working on a fix for this this an hour ago or so. I should have something up today or tomorrow :)
c0b commentedon Oct 24, 2017
or close the whole repo instead? or just close the issues board, leave the remaining at read-only mode for another period before eventually delete
http2: make sessions garbage-collectible
http2: make sessions garbage-collectible
http2: make sessions garbage-collectible
http2: make sessions garbage-collectible
http2: make sessions garbage-collectible