VishnuPriyaChandraSekar commented on code in PR #4626:
URL: https://github.com/apache/solr/pull/4626#discussion_r3626599897
##########
solr/solrj/src/test/org/apache/solr/client/solrj/impl/LB2SolrClientTest.java:
##########
@@ -405,6 +405,9 @@ private class TimeoutZombieTestContext implements
AutoCloseable {
new HttpJettySolrClient.Builder()
.withConnectionTimeout(1000, TimeUnit.MILLISECONDS)
.withIdleTimeout(1, TimeUnit.MILLISECONDS)
+ // override the infinite request timeout with idle timeout to
ensure idle requests
+ // times out.
Review Comment:
>"this test": LB2SolrClientTest is a test suite with a number of tests, and
this comment thread is on a general part of the test suite. Hopefully the
"connect" timeout ones are valid; yes? So I suppose your input is that the
"testTimeoutExceptionMarksServerAsZombie" test and Async one are flawed?
@dsmiley The issue only affects
`testTimeoutExceptionMarksServerAsZombieAsyncRequest`. Interestingly, the
synchronous counterpart, `testTimeoutExceptionMarksServerAsZombie`, does throw
a `TimeoutException`.
After digging into the code, it looks like the difference is that the
synchronous API waits for the response headers using
`listener.get(idleTimeoutMillis, TimeUnit.MILLISECONDS)`, where
`idleTimeoutMillis` comes from the request rather than the default infinite
idle timeout set at transport layer [1]. As a result, even though the transport
layer is configured with an infinite idle timeout, the application-layer
timeout prevents the request from hanging indefinitely.
The async API, on the other hand, doesn't have an equivalent
application-layer timeout and instead relies on the transport layer to trigger
`onHeaders()` or `onFailure()` [2]. Since the transport idle timeout isn't
applied at this stage, the future never completes and the test hangs.
[1]
https://github.com/apache/solr/blob/main/solr/solrj-jetty/src/java/org/apache/solr/client/solrj/jetty/HttpJettySolrClient.java#L484
[2]
https://github.com/apache/solr/blob/main/solr/solrj-jetty/src/java/org/apache/solr/client/solrj/jetty/HttpJettySolrClient.java#L402
> If the default idle timeout of -1 is actually used as such for the first
response, even in the beginning... this is a problem IMO. If we have the
intended/desired idle timeout then we can use that. If we don't, I suppose the
connection timeout would be a reasonable substitute.
Maybe we should a have timeout at the application layer like the sync call ?
(Not sure whether it is the right PR to fix the async call as it seem to be a
different problem)
Apologizes, if my findings weren't complete earlier. I found it hard to
debug as the timeout was triggered at different layer based on the request and
also tracing Java futures was hard. I hope now it make sense.
--
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]
