janhoy opened a new issue, #106: URL: https://github.com/apache/solr-orbit/issues/106
Thespian is effectively dormant, and it is the reason the cluster-provisioning integration tests cannot run on macOS. **Thespian's state.** 4.0.1 (March 2025) is the latest release; before that, 4.0.0 in February 2025 and 3.10.7 in January 2023. Single maintainer. Our pin `thespian>=3.10.1,<4.0.2` already allows the newest version, so there is nothing to upgrade to. **What it costs us on macOS.** Two independent hangs, both reproducible here, neither fixable in Solr Orbit: 1. `socket.getfqdn()` returns `1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa` — the PTR name for IPv6 loopback. Thespian's `getLocalAddresses()` feeds that to `getaddrinfo()`, which fails, and `Unable to get address info` is logged before the run stalls. 2. Forcing `multiprocQueueBase` removes that warning entirely, but the run still hangs right after printing the test-run id: main thread parked in `select_poll_poll`, a worker thread blocked in `lock_PyThread_acquire_lock`, Solr up and healthy, no progress in 150s. So it is not only address resolution, and swapping transports is not a workaround. **What upstream is doing.** - Rally is replacing Thespian with Ray Core: [elastic/rally#2209](https://github.com/elastic/rally/issues/2209). Their rationale lists the same workarounds we inherited — `no_retry`, `PoisonMessage`/`ChildActorExited` handling, logger-recovery hacks, a polling `WakeupMessage` loop in every actor, and the "offline actor system" fallback, which is our `actor.use_offline_actor_system()`. Their plan drops that fallback and always starts an ephemeral local Ray bound to 127.0.0.1 for single-machine runs. - OpenSearch Benchmark hit the same macOS failure in [opensearch-benchmark#89](https://github.com/opensearch-project/opensearch-benchmark/issues/89) and closed it by removing macOS from its supported platforms rather than fixing it. We are in neither position yet: `[tool.tox]` still declares `platform = linux|darwin`, so we claim macOS support for integration tests that cannot pass there. **Proposal.** Follow Rally's lead and move to Ray Core once #2209 is merged, so we inherit a design that has been worked through rather than solving it twice. Until then, either document macOS as unsupported for the cluster-provisioning integration tests, or run them on Linux in CI (filed separately) so the gap is covered by something other than a developer's laptop. Not urgent — single-machine benchmarking works fine on Linux, and on macOS everything that does not provision a cluster passes. Filing it so the dependency risk and the macOS gap are recorded rather than rediscovered. 🤖 Assisted by Claude Code -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
