[
https://issues.apache.org/jira/browse/SOLR-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687577#comment-17687577
]
Eric Pugh commented on SOLR-16595:
----------------------------------
Hi all.. I need to ask for help from the braintrust, as I'm pretty
frustrated with this effort... For some reason
"org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClientBuilderTest.testSocketTimeoutOnCommit"
fails frequently for me, but I can't for the life figure it out... It fails
frequently, but not always reliably... I can't tell if it's something I'm
doing, or a flaky test?
ERROR: The following test(s) have failed:
-
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClientBuilderTest.testSocketTimeoutOnCommit
(:solr:solrj)
Test output:
/Users/epugh/Documents/projects/solr-epugh/solr/solrj/build/test-results/test/outputs/OUTPUT-org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClientBuilderTest.txt
Reproduce with: gradlew :solr:solrj:test --tests
"org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClientBuilderTest.testSocketTimeoutOnCommit"
-Ptests.jvms=4 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:+UseParallelGC
-XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
-Ptests.seed=64A7B5D9DFAC5FB9 -Ptests.file.encoding=US-ASCII
Would love someone to look at either of the PR's I've pushed up and test
them... At this point I'm kind of out of ideas on this....
> Standardize Builder handling of times
> -------------------------------------
>
> Key: SOLR-16595
> URL: https://issues.apache.org/jira/browse/SOLR-16595
> Project: Solr
> Issue Type: Sub-task
> Components: clients - java
> Affects Versions: 9.0
> Reporter: Eric Pugh
> Assignee: Eric Pugh
> Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> COming out of another ticket:
> TimeUnit class was introduced in part to add clarity to call-sites of a
> method so the unit is clear. blah.setTime(TimeUnit.SECOND, 1) is fine as well
> as blah.setTime(TimeUnit.MINUTE,2) -- the caller picks the unit convenient to
> them. With that design, the method is designed unit-free -- definitely NOT
> with variables named "second" as you proposed since the unit could be
> anything. Internally (implementation of the setter), we need to pick a unit
> to standardize to on some internal field to store the result, and name the
> field to be clear as to what the internal unit chosen is. (e.g.
> retryExpirySecs). Again, that's internal, the caller choses a unit convenient
> to them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
