[
https://issues.apache.org/jira/browse/SOLR-15702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17431316#comment-17431316
]
ASF subversion and git services commented on SOLR-15702:
--------------------------------------------------------
Commit fd4b3c35d9d4366a62c28fbb620e987efdac70e5 in solr's branch
refs/heads/main from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=fd4b3c3 ]
SOLR-15702: Changelog entry
> Stabilize S3 Tests
> ------------------
>
> Key: SOLR-15702
> URL: https://issues.apache.org/jira/browse/SOLR-15702
> Project: Solr
> Issue Type: Test
> Components: contrib - S3 Repository
> Affects Versions: 8.10
> Reporter: Houston Putman
> Assignee: Houston Putman
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently all 3 tests in the {{S3IncrementalBackupTest}} fail sporadically
> (between 1-5% of the time on the jenkins instances).
> From my investigations, these failures mainly happen because S3Repository
> will create a directory node, and then assume it exists later on. However,
> the S3Mock may be too slow and later on when the assumption is made that this
> directory node exists, S3Mock is returning that the directory node does not
> exist.
> The first fix for this was to just always check twice to see if a node is
> there, kind of hacky but it gives the S3Repository one more chance to find
> the right information.
> However in the v2 S3 API, there is a concept of
> [waiters|https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/using.html#using-use-waiters],
> which will allow us to wait until S3 verifies the state we are looking for
> (i.e. that the directory node exists). We can either put this waiter in after
> creating the node, and not return until the waiter says the node is created.
> Or we can put it in when checking whether the node exists. I think the former
> is preferable, but we can do testing to see which actually preforms better.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
