[
https://issues.apache.org/jira/browse/SOLR-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687937#comment-17687937
]
Eric Pugh commented on SOLR-16595:
----------------------------------
so, [~dsmiley] figured out the actual bug in my PR.... I am still getting
intermittant failures locally, but it may be my slow laptop, not sure. Also
Crave ran a successful test post the bug fix:
https://github.com/apache/solr/actions/runs/4163746728/jobs/7204518282
Thank you for testing [~janhoy] as I started thinking I was crazy....
> 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: 1h
> 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
