http2: implement ref() and unref() on sessions

[kjin]

Fixes #16617

This is my stab at adding ref and unref on ClientHttp2Session instances. It seems mostly straightforward, but there were a few questions I had in mind about this code change:

• Should ClientHttp2Session instances be unrefd by default?
• Should these be available on ServerHttp2Session objects as well? (my thought is no)
• Should calling ref/unref be a no-op after the session has been destroyed, or could it return an error?

I saw this comment made by @addaleax about uv_prepare_t, but I don't really understand it. To me, this code change seems sufficient, but maybe I'm missing something.

Also, I updated the docs to separate ClientHttp2Session from Http2Session... which seemed to make sense considering that this distinction is present even in the codebase.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

http2

[addaleax]

I saw this comment made by @addaleax about uv_prepare_t, but I don't really understand it. To me, this code change seems sufficient, but maybe I'm missing something.

The code has changed since then. :)

Should ClientHttp2Session instances be unrefd by default?

I don’t think so; if you have an active network connection, you usually want that to keep the event loop alive.

Should these be available on ServerHttp2Session objects as well? (my thought is no)

Why not? :)

Should calling ref/unref be a no-op after the session has been destroyed, or could it return an error?

It seems doing nothing is what net.Socket does, so I’d go with that? I think that’s what this code already does, right? 👍

[addaleax]

Can you use added: REPLACEME here? That way it gets picked up automatically by the release tooling :)

[addaleax]

Can you also check whether typeof this[kSocket].ref === 'function'? HTTP/2 supports any stream as the underlying socket, so .ref might not be present at that point.

The test file that checks that is test/parallel/test-http2-generic-streams.js, if you want to extend that – I think calling .ref() there would crash right now?

[kjin]

Should these be available on ServerHttp2Session objects as well? (my thought is no)

Why not? :)

I thought http.Server instances didn't have them, but I now see that they inherit ref and unref from net.Server. I suppose I couldn't think of use cases for unrefing an http.Server earlier, but there's no reason now to not include them on Http2Session.

Seems like it's worthwhile to ensure unref works on Http2Server as well, so doing both now.

[addaleax]

@kjin I think those are different things – ServerHttp2Session corresponds to a single connection, Http2Server to the entire server, right? I’m not sure but they probably both have ref/unref methods?

[kjin]

Yep, I understand that ServerHttp2Session objects are created on a per-connection basis by an Http2Server instance, and isn't really an analogue of http.Server. I definitely skipped an explanation step there but what I was intending to say was "no reason why http2 server-side objects shouldn't also have ref and unref".

Currently ServerHttp2Session doesn't have unref, but Http2Server does. I think the latter doesn't do anything, and what I was saying above was that I might as well fix that now (whatever that entails). (edit: it actually does work)

[kjin]

@addaleax Thanks for the feedback so far, I've updated the PR to make ref and unref properties of Http2Session instead of ClientHttp2Session (and the docs accordingly). I kept the docs for ClientHttp2Session#request separate for the same reason as in the initial PR description. Can you take another look when you have the chance?

[jasnell]

This should wait to land until after #17406, as is may need to be updated based on those changes.

[TimothyGu]

@addaleax

Should ClientHttp2Session instances be unrefd by default?

I don’t think so; if you have an active network connection, you usually want that to keep the event loop alive.

Hmm, but if the session isn't transporting any data (just kept open because of HTTP/2 semantics) I don't see a good reason why it should keep the event loop alive.

[addaleax]

Why not just this[kSocket].ref? That’s what’s being called anyway, right?

[kjin]

For generic duplex streams this[kSocket] is a JSStreamWrap object, which doesn't have a handle.ref field.

Actually, this makes me think that net.Socket itself should be checking that _handle.ref is a function, rather than here. I'll add a trailing commit that does so, we can drop it if there is already a good rationale for not checking in net.

[addaleax]

@TimothyGu This is just calling through to the underlying socket, the HTTP2 session itself won’t keep anything open

[kjin]

@jasnell @addaleax I've rebased the PR on master. The only conflict was in the docs, since I moved http2session.request to a new ClientHttp2Session section. The rebased commits should reflect whatever changed in the docs since I first opened this PR.

I can understand if it's not in the scope of this PR to move the request docs, but I still think it makes sense considering that ClientHttp2Session is treated as a separate class in http2/core.js.

[jasnell]

CI: https://ci.nodejs.org/job/node-test-pull-request/12269/

[jasnell]

landed in 120ea9b

[ofrobots]

@gibfahn This still needs to be released on 8.x. Let myself or @kjin know if there is any work needed from our side to make that happen.

[gibfahn]

Thanks for the ping, not sure why this hasn't been backported yet.

[kjin]

@gibfahn This PR was originally contingent on #17406 landing, so I assume that the backport will be as well.