[
https://issues.apache.org/jira/browse/SOLR-17573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901170#comment-17901170
]
Andrzej Bialecki commented on SOLR-17573:
-----------------------------------------
I think a global singleton (configurable via sysprops or TestInjection) is a
reasonable approach.
I'm not convinced about using java.time.Clock .. First, directly it only offers
millisecond resolution so nano time is not immediately available, only inside
an Instant (with added object creation). This then makes even the simplest wait
loops very complicated with multiple conversions and allocations in order to
get eg. elapsed nanoseconds.
> Make TimeSource a global singleton; never a field or param of any code
> ----------------------------------------------------------------------
>
> Key: SOLR-17573
> URL: https://issues.apache.org/jira/browse/SOLR-17573
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Priority: Minor
>
> Time is an ever-present concept used in lots of code. TimeSource.java in
> Solr is an attempt to make it pluggable so that tests or simulations can
> manipulate it. However, it only applies to code that is using TimeSource,
> which presently is done by passing TimeSource all over the place across APIs.
> It's so annoying that I wish to change the approach. Proposal: make it a
> global instance that only tests/simulations might touch. Tests would need to
> reset it, of course.
> If we're truly wholistic about this, we might make System.nanoTime forbidden
> but... wow... maybe we should? If only the JDK's time was manipulatable.
> Finally; we aren't we using java.time.Clock which appears designed for
> pluggable time?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
