perf(server): virtual threads, hot-path log demotion, JMX guard, 64 KB LOB blocks

[Copilot]

Four targeted changes to reduce OJP proxy overhead on latency and throughput.

Virtual threads (was: fixed thread pool of 200)

// GrpcServer.java
- .executor(Executors.newFixedThreadPool(config.getThreadPoolSize()))
+ .executor(Executors.newVirtualThreadPerTaskExecutor())

Every gRPC handler that blocks on JDBC I/O previously pinned a platform thread. With a 20-connection pool, only 20 requests could execute SQL concurrently; the remaining 180 threads were parked. Virtual threads yield during blocking I/O and remove the hard throughput ceiling. ojp.server.threadPoolSize is preserved but now logged as ignored.

Hot-path log.info → log.debug

SLF4J evaluates arguments at INFO level regardless of whether any appender writes them — string allocation + timestamp construction on every SQL call. Demoted in:

• ExecuteQueryAction, ExecuteUpdateAction
• StartTransactionAction, CommitTransactionAction, RollbackTransactionAction
• SessionManagerImpl (session create/terminate/LOB lifecycle)
• CreateLobAction, ReadLobAction

JMX stats gated in ConnectionAcquisitionManager

HikariCP's getHikariPoolMXBean() methods acquire a brief internal pool lock. The stats-gathering block now only executes when:

• log.isDebugEnabled(), or
• a real metrics collector (not NoOpPoolMetrics) is active

Under default production settings (INFO, no OTel), the lock is never taken on the connection acquisition hot path.

LOB block size 1 KB → 64 KB

CommonConstants.MAX_LOB_DATA_BLOCK_SIZE: 1024 → 65536. A 1 MB BLOB previously required 1,024 block transfers; now 16, proportionally reducing LOB streaming latency and per-block gRPC serialisation overhead.

[sonarqubecloud]

Quality Gate passed

Issues
3 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