[ 
https://issues.apache.org/jira/browse/SOLR-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096844#comment-18096844
 ] 

Serhiy Bzhezytskyy commented on SOLR-17764:
-------------------------------------------

Upstream follow-up: I opened a Jetty PR for the root-cause bug — 
https://github.com/jetty/jetty.project/pull/15435 (fixes 
[jetty#15368|https://github.com/jetty/jetty.project/issues/15368]).

It fixes the HTTP/2 client aborting a fully-received response when the 
connection closes during graceful shutdown — the ClosedChannelException behind 
the TestGracefulJettyShutdown failures here. The fix skips aborting a channel 
whose last DATA frame has already arrived (isLastDataReceived()), so a 
completed-but-unconsumed response is delivered instead of discarded. Includes a 
deterministic white-box test.

Once that lands in a Jetty release and Solr picks it up, these 
graceful-shutdown test failures should clear. Until then the failure is 
upstream, not Solr-side.

> "graceful" jetty shutdown causes ChaosMonkeySafeLeaderWithPullReplicasTest 
> failures
> -----------------------------------------------------------------------------------
>
>                 Key: SOLR-17764
>                 URL: https://issues.apache.org/jira/browse/SOLR-17764
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Chris M. Hostetter
>            Priority: Major
>              Labels: pull-request-available
>         Attachments: 
> E7F93005B9386058.OUTPUT-org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.txt
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Reviewing recent jenkins test failure metrics, I noticed that (Nightly) test 
> ChaosMonkeySafeLeaderWithPullReplicasTest started failing ~60% of the time 
> right around the time that SOLR-17744 was committed.
> Things i have observed:
>  * Seeds from failing runs seem to reliably reproduce the failure
>  ** These failures do *NOT* reproduce if i revert to just before SOLR-17744
>  * Ad-hoc testing I've done of seeds that do _not_ fail on first attempt seem 
> to reliably succeed on all subsequent attempts
>  ** Suggesting that the root cause is something deterministic in the 
> {{{}random(){}}}-ness of the test, and not something dependent on timing or 
> concurrency.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to