[infinispan-dev] [Discussion] TimeService implementation

[Pedro Ruivo]

On 04/29/2013 05:53 PM, Mircea Markus wrote:
>
> On 29 Apr 2013, at 17:34, Pedro Ruivo wrote:
>
>> Hi,
>>
>> The TimeService interface is going to replace all the System.nanoTime()
>> and System.currentTimeMillis() in the code and it will allow to replace
>> in the test suite in order to provide a better control over the time
>> dependent code (if needed).
>>
>> The objective of this email is to discuss possible implementation and
>> interface that will cover the needs of everybody (or at least try it).
>> Later I'll create a JIRA and start the implementation (except if someone
>> really wants to implement it :P)
>>
>> * Interface:
>>
>> //return the current time in nanoseconds and milliseconds respectively
>> long nowNanos()
>> long nowMillis()
> What about time() and wallClockTime() with overloaded methods time(TimeUnit) and wallClockTime(TimeUnit)?

what is the semantic of wallClockTime()? I'm assuming that time() 
returns the current time in nanoseconds...

>>
>> //return the duration between now() and the startNanos/Millis
>> long durationNanos(long startNanos)
>> long durationMillis(long startMillis)
> +1
>>
>> //return the duration between start+ and end+
>> long durationNanos(long startNanos, long endNanos)
> besides return (endNanos - startNanos) does it do some sanity checks? if it's only for the difference i think the subtraction is simpler

yes, it should check if endNano >= startNanos. Also, I need it in the 
test suite to return always 1 in order to predict the throughputs, 
durations, waiting and holding times...

>> long durationMillis(long startMillis, long endMillis)
>>
>> Any other method? Maybe adding a TimeUnit parameter instead of duplicate
>> methods (e.g. now(TimeUnit))?
> both :-)
>> Maybe some convert() with double
>> precision, since the TimeUnit.convert(...) usually loses precision?
> only when moving from finer to coarser granularity, but that's to be expected.

I like to be precise :D

>>
>> (I need double precision for the Extended Statistics, but I can put this
>> converters in my classes)
>>
>> * Scope:
>>
>> Should the TimeService be in a cache or global scope? My vote is per
>> cache...
> +1
>>
>> * Configuration
>>
>> Should we provide a configuration to pass an implementation of the
>> TimeService interface? if yes, we may need to change the methods above
>> to return some interface (e.g. TimeStamp) in order to support almost
>> anything.
> I liked your idea to inject it in the ComponentRegistry. Perhaps a ComponentRegistry.setTimeService method?

I think that is better to register the DefaultTimeService and if the 
user wants to overwrite (i.e. us in the test suite), he can use 
ComponentRegistry.replaceTimeService(). The last method will register 
and rewire the component registry

>>
>> Any other subject? Thoughts?
>>
>> If I was not clear let me know...
>>
>> Cheers,
>> Pedro Ruivo
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> Cheers,
>