The GitHub Actions job "CI" on pekko-connectors.git/main has succeeded. Run started by GitHub user pjfanning (triggered by pjfanning).
Head commit for run: fd74c9506992a4dc511fe4dd33c88a806b1e6ec2 / PJ Fanning <[email protected]> Unix Domain Socket: fix large-transfer stall from lost readiness events (#1880) Motivation: UnixDomainSocketSpec's "send and receive more ten times the size of a buffer" test (disabled since 2019) stalls part way through the transfer: the echoing server never writes a byte, its receive queue then fills, and both directions deadlock. jnr-enxio's KQSelector registers kqueue filters edge-triggered (EV_CLEAR) and its poll() overwrites a key's readyOps for each kevent entry instead of OR-ing them. When EVFILT_READ and EVFILT_WRITE for the same channel arrive in one batch, the entry processed last clobbers the other's readiness, and the consumed edge never fires again. The event loop gated writes on key.isWritable and reads on key.isReadable, so a clobbered event stalled that direction forever. Modification: Attempt a pending write or read in the NIO event loop whenever the key is selected, rather than only when the (unreliable) ready ops report it. A non-blocking operation on a not-ready socket returns 0, which is now handled: an unfinished write keeps OP_WRITE registered and a 0-byte read is a no-op instead of being mistaken for EOF. This is self-healing: a readiness edge can only be lost to another event on the same key, and that event now triggers the retry. Re-enable the test. Result: Sustained transfers complete; the throughput test passes in ~250ms instead of timing out after a minute. Tests: - sbt "unix-domain-socket/testOnly docs.scaladsl.UnixDomainSocketSpec" (all 7 pass, stable over 5 consecutive runs; the re-enabled test reproduced the stall before the fix) References: Fixes #1858 Report URL: https://github.com/apache/pekko-connectors/actions/runs/35713378122 With regards, GitHub Actions via GitBox --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
