tballison commented on PR #3254:
URL: https://github.com/apache/tika/pull/3254#issuecomment-5831099810
:robot: 's diagnosis:
```
The ZooKeeper "GET" errors came from the reporter's browser. Port 55473 is
ZooKeeper's 9983 mapped to the host, and they said they opened it and got
NS_ERROR_NET_EMPTY_RESPONSE. The
errors come in two bursts of about ten, one per second (02:49:38–47 and
02:50:33–43), which looks like Firefox retrying. The Solr admin UI calls at
02:50:06 (_=... cache-busting params)
are them opening 55474. None of this affects the test.
Solr was ready early and answered every health check. It was serving by
02:48:31, the reverse-DNS fix from #3230 took effect ("prevented due to
'solr.dns.prevent.reverse.lookup'"), and
every /admin/info/system probe was answered with status=0 in 10–40 ms.
That continued until about 02:51:16, which is where the 3-minute startup
timeout ends.
Why Testcontainers never accepted it: in Testcontainers 2.0.5,
HttpWaitStrategy has a default readTimeout of 1 s and a rate limit of one
attempt per second.
- If the probes were getting a non-200 back, they'd fail instantly and
repeat about once a second.
- The log shows exactly one probe every ~2.0 s. That's the 1 s wait for a
response plus the 1 s rate limit.
- So Solr answers in about 15 ms, but the response doesn't reach the JVM
on that Windows box within 1 s. The likely culprit is Docker Desktop's port
forwarding or local security/proxy
software, though I can't tell which from this log.
- The browser worked because it waits much longer than 1 s.
- The old hand-written loop removed in #3230 also used
setReadTimeout(1000). That's why neither version worked.
```
--
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]
