bernardladenthin / BitcoinAddressFinder / 26057283338

77%

push

github

Support indefinite blocking in queue-based key producers (#204)

* Fix flaky KeyProducerJavaZmqTest by eliminating sender LINGER=0 race

Root cause: jeromq's ZContext defaults to linger=0. When the sender
thread's try-with-resources block closed its ZContext, any message still
buffered in the PUSH socket's outbound queue was silently dropped. The
previous fix (PR #149) added a 300 ms Thread.sleep after send() to give
ZMQ time to flush — too tight under Windows CI load, so the test still
timed out at the 2000 ms poll on the producer side.

Fix: structurally remove the race rather than chase timing margins.

- createSecrets_success_receivesOneKey and createSecrets_multipleKeys_success
  now create the PUSH sender in the main thread inside the test-spanning
  try-with-resources, mirroring createSecrets_connectMode_receivesSecret.
  The sender's ZContext stays alive for the entire createSecrets() call,
  so LINGER=0 never gets a chance to drop pending messages, and there is
  no executor-scheduled sender thread whose start can be delayed under
  load. The CountDownLatch + Thread.sleep synchronization is gone.

- New TestTimeProvider.RECEIVER_THREAD_TIMEOUT (20_000 ms) and applied
  by default in createBindConfig / createConnectConfig. The previous
  2000 ms (DEFAULT_SOCKET_TIMEOUT) gave the producer's receiver thread
  too little slack on CI runners where the ZMQ I/O thread can be briefly
  starved by the OS scheduler.

Verified by running KeyProducerJavaZmqTest repeatedly under CPU
saturation; the structural fix plus the wider timeout brings the
single-key test to a clean pass rate under conditions where the
previous code consistently timed out.

* Restore -1 = block-forever timeout semantics; test it for real

Before commit fbe6f4a7 (Dec 2025) the ZMQ producer was synchronous and
CKeyProducerJavaZmq.timeout defaulted to -1, meaning "block until a
message arrives". When that commit introduced the receiver-thread +
BlockingQueue architecture, -1 silently ... (continued)

444 of 602 branches covered (73.75%)

Branch coverage included in aggregate %.

1873 of 2437 relevant lines covered (76.86%)

3.47 hits per line