anton-vinogradov commented on PR #13352:
URL: https://github.com/apache/ignite/pull/13352#issuecomment-4938184324
I've dug into the hangs, and I believe the classpath change doesn't affect
them, unfortunately:
1. `AppendTestClasses("modules")` already walks every direct subdirectory of
`modules` and appends `modules/commons/target/classes`. The explicit calls
exist only for parents with nested modules (`modules/binary/*`,
`modules/thin-client/*`), and `modules/commons` has no nested modules — so the
new line adds nothing to the classpath.
2. The Windows 1 run on this very PR hung at the same position as all other
affected builds ("Tests passed: 1490", then execution timeout), and the
hung-build logs contain no class-loading errors at all.
3. The same revision both passes and hangs (e.g. master builds 9190207 vs
9191076), including pairs that consumed identical Build artifacts (9193992 vs
9198016) — so the hang is not classpath-dependent.
What actually hangs (thread dump of a reproduced stuck start): the embedded
node spins forever in `ServerImpl.sendJoinRequestMessage` / `joinTopology`. If
discovery port 47500 is occupied at node bind time (lingering teardown of the
previous fixture / a half-stopped node), the new node binds 47501+, while the
tests' static IP finder only knows `127.0.0.1:47500`, and the default
`joinTimeout=0` retries forever — eating the whole 120-minute suite timeout.
Each suite hangs at its first vulnerable node start, hence the stable positions
(1490/1342/78).
I've put up an alternative fix: #13357 — a finite `JoinTimeout` plus a
capped `MaxAckTimeout` in `TestUtils.GetStaticDiscovery()` and in the
`app.config` discovery sections, plus the forgotten `Localhost=127.0.0.1` in
two test configs. Verified locally: with a process squatting 47500, the test
now fails in ~2.5 minutes with "Failed to connect to any address from IP finder
within join timeout" instead of hanging forever.
That said, there IS a separate class-mixing failure, which you may have been
chasing: build 9198139 (Windows 1, pull/13347) failed 2032 tests with
`NoSuchMethodError` on methods relocated by the thin-client extraction
(`CommonUtils.join(GridWorker, IgniteLogger)`,
`MarshallerUtils.processSystemClasses(ClassLoader, Consumer)`). The Build
artifact there is clean — `CommonUtils.class` inside its ignite.zip does
contain the method (checked with javap). The real difference: that run used an
*incremental* checkout ("Building incremental patch ... 8d78bb04 -> a700ad47",
and the previous tree in that work dir was a branch based on the pre-relocation
master), while every healthy run shows "Clean build enabled". So stale unpacked
`target/classes` of the previous branch mixed with the new ones — no
`Classpath.cs` change can help with that; the checkout has to be cleaned. This
deserves a separate ticket, will file one.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
