feat(backend): use global connection pool #376
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Move the connection pool to the global dimension to ensure connections are properly reused.
Currently, the connection pool is created when creating instances of the backend implementation class, which was sufficient for the one-time CLI mode.
However, in ADC server mode, this caused a new connection pool to be created for every sync request, and kept old connections and prevented reuse. This was a completely unintended state and must be fixed.
This PR moves connection pool creation to the top layer and passes it to each backend instance, preventing backend instances from maintaining their own connection pools.
Additionally, it replaces the use of Node.js's native HTTPAgent and HTTPSAgent with the agentkeepalive library. Some helper functions within this library will assist us in maintaining idle connections at relatively low levels by closing excess connections.
As a trade-off, the ADC server mode temporarily loses the ability to use mTLS and validate server certificates. This is because HTTPSAgent is statically configured, which prevents us from defining specific TLS configurations for particular requests. Since its primary use case, the APISIX Ingress Controller, does not support mTLS-based Admin APIs, this is not currently an issue.
We will address this issue in a future pull request. For example, we will establish dedicated connection pools for each host instead of maintaining all connections in a single pool.
Checklist