Repository navigation
Several IpmiClient instances in one JVM against the same BMC: only one of four succeeds #97
Description
Activity
Re-measured on 2026-10-09 with an in-JVM harness (4 threads, each its own
IpmiConnector,getChassisStatus()+getSensors()against the same BMC), onmain(1abf019, which carries the transport fixes of #140 and #142) and on the lifecycle/thread-safety branches (#148 and the follow-up PR for #96/#89).GIGABYTE ME62 (the BMC of this report), 4 workers in one JVM:
Build Run 1 Run 2 main4/4 OK (2.6 s each) 4/4 OK (3.9 s, one worker 7.5 s after a lost reply) lifecycle + thread-safety 4/4 OK (2.5 s each) 4/4 OK (2.5 s each) The 1-of-4 result of the report came from the 300 s message timeout and the broken sync retry: a dropped reply stalled the worker for the whole call. #140 (5 s per-message timeout, retry waits for the resent request) fixed that, so the in-JVM scenario now passes on
main.Supermicro SYS (ipmi-hci-stg-01), where 2 of 4 workers still fail, in ~300 ms, with
IPMIException: Inactive session ID.: the failure is the BMC's, not the library's.- 4 workers in one JVM: 2/4 OK (five runs, always exactly 2);
- 2 workers in one JVM: 2/2 OK; 3 workers: 2/3 OK;
- 4 separate JVMs started at the same time: 2/4 and 3/4 OK;
- 4 simultaneous
ipmiutil health -F lan2 -J 3sessions: 2/4 then 3/4 OK, the others fail withUnable to establish IPMI v2 / RMCP+ session; 2 simultaneous: 2/2 OK.
That BMC accepts about two RMCP+ sessions being opened at the same time; the extra ones are evicted. The Thread safety section of the documentation already says that parallel sessions against the same BMC are not reliable.
No packet capture was needed: the same client in separate processes and an independent client reproduce the Supermicro limit, and the GIGABYTE scenario passes.
Closing: the reported scenario passes since #140, and the remaining Supermicro failure is a BMC-side session limit (see the measurements above).
Where: client layer +
core/connection; root cause not fully isolated.What happens: Running 4
IpmiClient.getChassisStatus()+getSensors()workers concurrently in one JVM against the same BMC (each worker creates its ownIpmiConnectoron an ephemeral port) gives 1 success and 3TimeoutException(60 s). Two simultaneous workers: 0 of 2. Chassis status (one in-session message) succeeds for all workers; the losses start on the second in-session message of each SDR walk, at the same millisecond for both sessions.What is BMC-side and what is ours:
ipmiutilsessions (health, and FRU reads) all succeed in < 2 s – two of them visibly retried once, so this BMC does drop some packets under concurrent sessions.So part of the problem is the 300 s timeout and the broken sync retry (separate issues), but in-JVM concurrency is measurably worse than separate processes, which points at shared state or the races listed in the data-race issue (
UdpMessenger.send()issynchronizedwith a 1 ms sleep per packet, staticConnectionManager.reservedTags, etc.). A packet capture comparing the two setups would settle it. MetricsHub polls many hosts from one JVM, so this matters.