Issue: Conflict when using MilvusClientV2Pool: Wasted H2 multiplexing capability

[systemview2018]

Describe the Problem

When integrating Apache Commons Pool (general-purpose object pool) with MilvusClientV2 (Milvus Java SDK v2.x) in MilvusClientV2Pool, there's a critical conflict that wastes the multiplexing capability of HTTP/2 (H2) — the underlying transport protocol of gRPC used by MilvusClientV2.

Background & Technical Context

1. MilvusClientV2 gRPC/H2 Foundation: MilvusClientV2 relies on gRPC, which uses H2 as the transport layer. H2's core advantage is single Channel multiplexing — multiple concurrent RPC streams can share one TCP connection, avoiding redundant connections and optimizing resource utilization.
2. Apache Commons Pool Behavior: Commons Pool is designed for generic object lifecycle management (borrow/return/idle/destroy). However, it has no built-in awareness or adaptation for H2 protocol features (e.g., multiplexing, concurrent stream limits, shared Channel management).

Current Conflict & Impact

When pooling MilvusClientV2 instances with Commons Pool:

• Redundant H2 Connections: By default, each pooled MilvusClientV2 creates an independent gRPC Channel (and thus an independent H2 TCP connection). This completely negates H2's multiplexing design, leading to unnecessary resource consumption (TCP connections, memory) and reduced performance.
• Misalignment with H2 Stream Control: H2 has a default concurrent stream limit (100 streams per Channel). Commons Pool cannot recognize this limit, so it cannot adapt pooling logic to avoid exceeding H2's constraints (e.g., no coordination between pool maxTotal and H2's max concurrent streams).
• Wasted Optimization Potential: The core value of H2/gRPC (efficient multiplexing) is lost, making the object pool a counterproductive layer in this integration scenario.

Expected Behavior

We expect a way to use Apache Commons Pool with MilvusClientV2 while:

1. Retaining H2's multiplexing capability (all pooled MilvusClientV2 instances share a single gRPC/H2 Channel).
2. Aligning pool management with H2's features (e.g., respecting H2's concurrent stream limits, avoiding redundant connections).

Questions for Maintainers

1. Is there an official recommended approach to resolve this conflict? (e.g., custom PooledObjectFactory for shared H2 Channel, or alternative pooling strategies compatible with MilvusClientV2's gRPC/H2 design)
2. Are there plans to optimize MilvusClientV2's compatibility with common object pool frameworks like Apache Commons Pool, to better leverage H2's multiplexing?
3. If a custom integration is required (e.g., shared Channel in pool factory), are there any SDK-specific constraints or best practices to avoid stability issues (e.g., Channel lifecycle management, thread safety)?

[yhmo]

Normally, a single instance of MilvusClient can meet most of the requirements due to the multiplexing capability of HTTP/2. The maximum concurrency is eventually limited by the concurrent stream limit (100 streams per channel). In high-load scenarios, gRPC officially suggests that using multiple channels could be a solution:
https://grpc.io/docs/guides/performance/

The RPC interfaces of each MilvusClient are thread-safe, allowing one MilvusClient to work with many threads. If the MilvusClientPool is used for "getting a client, making one call, and returning" it wastes resources to hold many MilvusClient instances. We need a better design here.

MilvusClient was implemented before MilvusClientPool, which limits the pool's implementation. In my opinion, there should be an abstract MilvusClient interface, and a lightweight class, MilvusClientWrapper, should be derived from it.

The MilvusClientPool should maintain some extensible pools of MilvusClientImpl, and getClient() should return a MilvusClientWrapper instead of MilvusClientImpl. MilvusClientWrapper should have almost the same interface as MilvusClientImpl, except for connection and closure operations. MilvusClientWrapper is lightweight, can be discarded after an RPC call, and does not need to be returned.

I think a pool of MilvusClientImpl is stll necessary since a single channel's concurreny ability is limited by the internal concurrent stream limit.

[systemview2018]

It is very good design. For the first 100 getClient request, just return the 1st wrapper. and go on.

[yhmo]

The fix pr has been merged: #1732
Will be released in v2.6.11

Note: the original interfaces are not changed, just add a cache layer between the ClientPool and Apache common pool.