Http2Server.prototype.close Does Not Work as Expected

[anliting]

• Version: v12.4.0
• Platform: Linux pcd 5.1.8-arch1-1-ARCH deps: update openssl to 1.0.1j #1 SMP PREEMPT Sun Jun 9 20:28:28 UTC 2019 x86_64 GNU/Linux
• Subsystem: http2

node-v12.4.0-linux-x64/bin/node a.js

let
    http2=require('http2'),
    server=http2.createServer()
server.listen(8000,'127.0.0.1',()=>{
    let client=http2.connect('http://127.0.0.1:8000',()=>{
        console.log('listener called')
        server.close(()=>{
            console.log('close')
        })
    })
})

Expected: server.close stops the server from accepting new connections.
Result: console.log('close') never get called.

I aware that HTTP/2 works different to HTTP/1.1. And I can and should call session.close() on every active session to stop them from accepting new requests.

server.close seems also wait until there is no active sessions to call the callback function, which is not mentioned in the documentation.

And, to make there is no active sessions, I must first of all stop the server from accepting new connections.

[lpinca]

server.close seems also wait until there is no active sessions to call the callback function, which is not mentioned in the documentation

I guess it wasn't documented because the behavior is the same of net.Server.prototype.close(). The callback is not called until there is an open connection.

[cjihrig]

I think this is behaving as documented.

[anliting]

Oh, I see, it is documented. The callback is called when the server is closed, and the server waits, until there is no active connection, to close.

But I think the point is not whether it is documented or not:

An asynchronous operation usually call its callback function right after the operation is done.

As net.Server.prototype.close is documented, the operation is defined as "Stops the server from accepting new connections and keeps existing connections.". But the callback also waits until the server is closed to be called, rather than right after the operation is done.

Of course, it is not common does not mean it is bad. But think of the following situation:

Now I want to force a server to be closed with the following algorithm:

1. stops the server from accepting new connections
2. close all active connections

The second step must be executed after the first step. As the first step is an asynchronous operation, I would wait for its callback function to be called, to ensure that it is done. But the callback is called also implies that the second step is done. It is a dead lock.

Another approach:

1. close all active connections
2. stops the server from accepting new connections

It will not work, because once the server is still accepting new connections, there is no way to close all active connections in finite amount of steps.

[lpinca]

1. Stop the server from accepting new connections.
2. Close all active connections.
3. Wait for the callback.

There is no need to wait for the callback before closing connections. No new connection is established after server.close() is called.

[anliting]

No new connection is established after server.close() is called. @lpinca

net.Server.prototype.close:

Stops the server from accepting new connections and keeps existing connections. This function is asynchronous, the server is finally closed when all connections are ended and the server emits a 'close' event.

If the function is defined to "stop the server from accepting new connections and keep existing connections", and the work is done before it returns, I would rather say that it is synchronous instead of asynchronous; saying that it is asynchronous means that, only through waiting that callback, I can ensure the work is done.

However, the function is named close, and it, in a sense, closes the server; its current behavior still makes a sense (stop ..., and wait until all connections are ended). It can be explained in the documentation, that: The closing of a server, involves

• stoping it from accepting new connection (synchronous), and
• waiting until all connections are ended (asynchronous); and this function does the both.