Evaluate the following idea:
Add new information to the SessionInfo returned to clients, the extra info will be 2 new fields:
1 - the number of clients connected to that datasource with same user and ...

Evaluated in commit 028c38e — a new section "Option: Server-Cooperative Fair-Share Throttling via SessionInfo" was added to CLIENT_REACTIVE_THROTTLING_ANALYSIS.md.

Summary of findings:

The formula works, but two things need to be pinned before implementation:

1. Is maxAdmission per-node or cluster-aggregate? The formula multiplies by numOjpServers, so if maxAdmission is per-node the result is correct; if it's cluster-aggregate the multiplication is wrong. Must be decided upfront.
2. What does clientCount count? It must be distinct clientUUID values (JVMs) per connHash, not raw session/connection count — otherwise a single JVM with a 50-connection pool would inflate the count by 50 and collapse everyone's limit.

Main risks identified:

• Integer division wastes capacity: floor(20/7) = 2, leaving 6 slots permanently unused. Ceiling division + a 10% safety headroom is safer.
• Thundering herd on client disconnect: When several clients drop, every remaining client gets a larger budget simultaneously and may burst together. A step-limited increase (AIMD-style) mitigates this.
• Semaphore resizing is non-trivial: java.util.concurrent.Semaphore has no setPermits(). The driver must track currentLimit separately and safely release/acquire the delta.
• Cross-node clientCount accuracy: In multinode mode, each node only sees its own clients. Recommended v1 approach: use per-node snapshot (conservative, slightly over-throttles), document it clearly, and add cluster-aggregate gossip in a later version.
• In-transaction bypass: Mid-transaction statements must skip the local semaphore or they risk deadlocking while the server waits for commit/rollback.

Positive: clusterHealth already carries the node UP/DOWN list, so numOjpServers can be derived from it without a new field. maxAdmission = 0 can cleanly mean "admission control not configured → no client-side limit."

Overall this design is materially better than purely reactive for steady-state behavior. The protocol cost (two int32 fields on SessionInfo) is minimal.

@copilot
1 - I believe maxAdmission is per-node, check the code and confirm.
2 - clientUUID values (JVMs) per connHash is correct.

Use Ceiling division + a 10% safety headroom and document the rational.

Do include A step-limited increase (AIMD-style) and document the rational.

In relation to "Semaphore resizing is non-trivial" is there any cheap(efficient) alternative to control concurrency that can be easily resized and that does not add latency in the flow?

"Cross-node clientCount accuracy" I do not understand what this means, explain in simple language with simple example.

"In-transaction bypass" , I am not sure if this is a problem, explain in simple language with a simple example.

Keep only the analysis for now, do not change the code yet.

@copilot
1 - I believe maxAdmission is per-node, check the code and confirm.
2 - clientUUID values (JVMs) per connHash is correct.
...

Updated in commit c9b629c. Here's what changed:

1. maxAdmission is per-node — confirmed.
SlotManager.totalSlots is set to actualPoolSize (the HikariCP connection pool size on this specific node). The formula multiplying by numOjpServers is therefore correct. This is now documented in the proposal section, marked resolved in Q1, and the Cons #4 "ambiguous" note has been replaced with a confirmation.

2. clientUUID per connHash — confirmed and resolved in C1.

3. Ceiling division + 10% headroom. S1 now explains the rationale: floor division leaves capacity permanently wasted; ceiling slightly over-allocates, which the 10% headroom compensates for by absorbing one stale clientCount error.

4. AIMD step-limited increase. S4 now has the full algorithm: decrease applies immediately (fast overload response), increase is capped at min(newLimit, currentLimit + 1) per SessionInfo update. Rationale is documented with an example showing how 4 simultaneous disconnects without AIMD would spike all remaining clients at once.

5. Semaphore alternative. The new Con #5 shows that a simple AtomicInteger counter + volatile int limit is the right choice for fail-fast (non-blocking) control. Resizing is a single volatile write — zero overhead on the happy path (one atomic increment + one comparison). No drain/inject logic needed.

6. Cross-node clientCount — plain-language example added. Con #8 now shows concretely: App1→Node A, App2→Node B, each node sees only its own client (clientCount = 1), both clients compute (10/1)*2 = 20 permits but total cluster capacity is only 20. Safe v1 approach: accept per-node snapshot; server's own SlotManager remains the final safety gate.

7. In-transaction bypass — plain-language example added. C5 now walks through the step-by-step scenario where Thread A holds an open transaction, the client semaphore fills, Thread A blocks waiting for a permit, and the server's transaction timeout fires before Thread A ever sends its next statement. Fix: skip the inFlight check when autoCommit == false.

@copilot we should have two modes configurable, proactive and reactive, in the proactive mode we do the client trottling with the atomic integer and fail fast as suggested, if reactive mode I want to ...

Evaluated and documented in commit 014e56e. The new sections added are:

Two-Mode Framework — a short overview table comparing proactive, reactive, and combined modes, showing what each requires and recommends.

Reactive Mode with observedPeak — Deep Analysis — full evaluation of the idea:

How it would work in SlotManager:

• Add highWaterMark (tracks peak in-flight count) and observedPeak (initialized to maxAdmission)
• On wait-timeout: observedPeak = max(floor, min(observedPeak, currentActive))
• AIMD recovery: every totalSlots × 2 successful releases: observedPeak = min(maxAdmission, observedPeak + 1)
• Sent as a third int32 field in SessionInfo; clients use it in place of maxAdmission in the fair-share formula

Main concerns raised:

1. "False floor" collapse — a single slow query or DB blip can drive observedPeak to near-zero. Fix: 10% floor (max(1, totalSlots * 0.1)).
2. Recovery rate tuning — too fast = burst risk, too slow = wasted capacity. K should be configurable.
3. Timeout path ambiguity — only the semaphore wait-timeout is a clean signal; queue-depth rejections may produce misleading counts.
4. SQS interaction — a slow-lane timeout ≠ total server overload; using activeSlow + activeFast total is safer than per-lane.
5. Multiple concurrent timeouts race — AtomicInteger.updateAndGet with a pre-snapshotted currentActive handles this correctly.

Opinion (confidence: 85%): The idea is sound — it's the TCP CWND model applied to OJP. The "false floor" and recovery rate are the only significant risks and both have clear mitigations. The recommended v1 is combined mode: send both maxAdmission and observedPeak, driver uses min(proactiveLimit, reactiveLimit). Reactive-only (no clientCount tracking) is simpler and could be the right first cut if fairness between clients is not the immediate priority.

@copilot the documents are too verbose, reduce the volume of information and focus on the latest ideas and solutions we're discussing, keep notes of previous ideas considered and why they were dropped...

Done in commit c265470.

• CLIENT_REACTIVE_THROTTLING_ANALYSIS.md: 1012 → 177 lines. Now structured as: protocol additions → proactive mode (formula, AtomicInteger, AIMD, in-transaction bypass, cross-node caveat) → reactive mode (observedPeak, risks table, mitigations) → combined mode → open questions → summary table → "Dropped Approaches" (purely client-reactive, Semaphore, floor division — each with a one-line reason why dropped).
• JDBC_SERVER_TRIGGERED_THROTTLING_OPTIONS.md: 222 → 74 lines. Now a concise options-considered log with a forward reference to the current design doc. Resolved option sets (signaling method, computation method, queue scope) are collapsed to one-liners showing what was chosen and why alternatives were skipped.

@copilot
I have run tests with the tool https://github.com/rrobetti/stressar/ and it is returning errors when running with this pr version of OJP

Error Breakdown

...

Fixed in commit f663238.

Root cause: When the server returned RESOURCE_EXHAUSTED (slot admission timeout), the exception propagated through Statement.executeQuery/executeUpdate but nothing updated ClientThrottleManager's reactive limit. The reactive limit stayed at MAX_VALUE, so the very next request was allowed through and hit the still-overloaded server again — causing the repeated server-side rejections you saw.

What changed:

1. ClientThrottleManager.notifyServerOverload() — new method that applies an AIMD multiplicative decrease: halves reactiveLimit (e.g. 8 → 4 → 2 → 1). If reactiveLimit was uninitialised (MAX_VALUE), it seeds from half the proactive limit so the client immediately backs off on the very first overload signal.

2. Statement.executeQuery/executeUpdate — now catch StatusRuntimeException(RESOURCE_EXHAUSTED) and call notifyServerOverload(). After the first server rejection, the client's reactive limit drops to half, and subsequent requests are blocked client-side (SQLTransientException) without touching the server.

3. PreparedStatement.executeQuery/executeUpdate — were completely unguarded before (no acquireThrottle call at all). They now have the same throttle acquire/release and notifyServerOverload() protection as Statement.

4. Extracted a shared onServerOverload() helper in Statement (protected, so PreparedStatement can reuse it) to avoid the duplicated catch block across four methods.

@copilot the errors remain, I noticed they only occurr when slow query segregation is enabled.

@copilot the errors remain, I noticed they only occurr when slow query segregation is enabled.

Fixed in commit 8aaaab3. Two root causes identified:

Root cause 1 (driver) — ClientThrottleManager.updateFromSessionInfo() was resetting reactiveLimit = MAX_VALUE on every SQL response. executeUpdate and executeQuery responses carry a minimal SessionInfo with maxAdmission=0; the old else branch treated that as "uninitialised" and reset the limit, silently undoing every notifyServerOverload() reduction on the first successful query. Fix: early return when maxAdmission <= 0.

Root cause 2 (server) — ConnectAction always sent maxAdmission = totalSlots regardless of the SQS fast/slow split. With the default 20% slow split (fastSlots=8, totalSlots=10) the client's proactive limit (floor(10 × 0.9) = 9) exceeded the 8 fast-lane slots, causing an immediate admission timeout on the 9th concurrent request. This is why the problem only appeared with SQS enabled — without SQS, fastSlots = totalSlots so proactiveLimit = 9 < 10 → no overflow. Fix: SlotManager.getEffectiveMaxAdmission() returns fastSlots when slowSlots > 0, totalSlots otherwise; ConnectAction now calls this method.

@copilot review your last fix, I have double the load and the errors now appear in both SQS and non SQS

non SQS

Error Breakdown

SQS

Error Breakdown

@copilot create a simple and easy to follow with flow diagram mermaid to explain how the throttling works. Use simple examples to explain. avoid being too verbose.

@copilot create a simple and easy to follow with flow diagram mermaid to explain how the throttling works. Use simple examples to explain. avoid being too verbose.

Added a simple Mermaid flow plus two short examples in documents/analysis/CLIENT_REACTIVE_THROTTLING_ANALYSIS.md to explain throttling in an easy-to-follow way. Commit: ccd8cfa.

@copilot

In documents/analysis/CLIENT_REACTIVE_THROTTLING_ANALYSIS.md...

Fixed in 8d29ff7. I replaced the Mermaid node labels with parser-safe quoted text (removed HTML line breaks and formula symbols from node bodies), and verified the diagram block now uses GitHub-compatible syntax.

@copilot now you went to the opposite level 120-slot pool is too much for an example use 40 and adapt everything else to thatscale in the analysis file

Updated in 1ddbd94. I changed the analysis examples to a 40-slot scale and adjusted the related numbers consistently (intro scenario, computed limit, and normal-mode example).

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud