Q about agent and keepAliveMaxTimeout

[nocquidant]

Hi, I have a couple of questions to ask. Thanks for your help.

Context:

• using undici from an aws lambda perspective
• see my code below

1st question: When I use a per-request agent, do I have to explicitly close it?

2nd question: Regarding keepAliveMaxTimeout, is the check done before getting a connection from the pool (which could happen after keepAliveMaxTimeout seconds if there is no activity)? Or is there a timer or something that will wake up after an inactivity period of keepAliveMaxTimeout seconds, and close the connection?

So if there is a timer and I understand correctly, after keepAliveMaxTimeout and without activity, no more TCP connection should be left open in the pool...

Thanks a lot for your work!

async requestUrl(url: string, opts?: HttpOptions): Promise<ResponseData> {
	let agent = this.#defaultAgent;
	if (opts) {
		// TODO Do we need to close the created agent?
		agent = new RetryAgent(new Agent({
			connectTimeout: opts?.connectTimeout ? opts?.connectTimeout : 30 * 1000,
		}), {
			maxRetries: opts?.withRetries ? 3 : 0
		});
	}

	try {
		const {
			statusCode,
			body
		} = await request(url, {
			dispatcher: agent,
			...opts?.request
		});
		const data = await body.text();
		return { statusCode, data }
	} catch (error) {
		return {
			statusCode: 500,
			data: (error as Error).message
		}
	}
}

[mcollina]

1. 1st question: When I use a per-request agent, do I have to explicitly close it?

Likely so

2nd question: Regarding keepAliveMaxTimeout, is the check done before getting a connection from the pool (which could happen after keepAliveMaxTimeout seconds if there is no activity)? Or is there a timer or something that will wake up after an inactivity period of keepAliveMaxTimeout seconds, and close the connection?

The check is done inside the client to verify if the connection must be reset.

---

You'd get best performance by having a short keep alive and reusing the agent

[nocquidant]

Thank you for the quick reply!

Hmm, your 2nd answer bores me.

As you know, we cannot be notified when the runtime execution (or sandbox) of the AWS lambda function is stopped by AWS.

But we know (from experience) that the sandbox will remain alive for at least 10 minutes (maybe much more, but after 10 minutes of inactivity, it is risky to consider it alive).

So I thought setting keepAliveMaxTimeout to 10 minutes would be ok. But this is not the case, because the check is performed when the client requests a connection to the pool.

I guess I need to implement some sort of timer at my lambda function level, and close all the connections from the pool after 10 minutes of inactivity from the lambda function point of view.

How can I close all TCP connections from the undici pool, while still keeping the pool functional if a new connection arrives?

Thanks again.

[mcollina]

So I thought setting keepAliveMaxTimeout to 10 minutes would be ok. But this is not the case, because the check is performed when the client requests a connection to the pool.

How is this a problem? This actually guarantees that the check is performed without having a race condition for an event. Note that if this check is failing, a new socket is allocated.

How can I close all TCP connections from the undici pool, while still keeping the pool functional if a new connection arrives?

This should be handled automatically for you.

[nocquidant]

If the client connection is renewed when requested from the pool, AWS will destroy the Lambda sandbox with all open connections in the pool. Which is not optimal from the server's point of view (resource leak).

[nocquidant]

I'll try :)

This is my undestanding so far:

	AWS Sanbox                                                                     SRV		
<-----------------------------------------------------------------------------> | <---------->

1. (my code) init an http request
         2. (undici) check the existing socket from the pool
         3. (undici) test: (currentTime - socket.lastUse) > keepAlive => renew the socket
         4. (undici) use the new socket to make http call to the server

5. (aws) 10 minutes pass without activity => Sanbox is killed 
                                                                                  6. (srv) tcp socket are still in a "pending" state

[mcollina]

This is correct. It's also true that if you have lambdas that have 10 min without activity the impact on the server is negligible, i.e. it's 1 socket.

The advantage of having a "ready" socket is better, because in this way you can having TCP+TLS handshakes.

[nocquidant]

Yes, actually i want keep alived sockets.
My main concern is that when AWS destroys the lambda function, the server is not aware of it (no TCP reset -> hard shutdown from AWS)
So this can cause a memory leak on the server, because 1 lambda is one connection, but there can be many lambdas.
I was thinking of a way to mitigate it...

[mcollina]

So this can cause a memory leak on the server, because 1 lambda is one connection, but there can be many lambdas.

There is no long-term leak, the server will clean things up over time. The timeouts could actually be configured there too.

[nocquidant]

Absolutely, but the server(s) is not under my responsability, so I am not very confident.
I would probably have preferred that my socket closed automatically after 10 minutes of inactivity.