[infinispan-dev] [Discussion] TimeService implementation

[Galder Zamarreño]

Hi Pedro,

On Apr 29, 2013, at 6:34 PM, Pedro Ruivo <pedro at infinispan.org> 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).

Great idea, hopefully it will make time related tests more reliable :).

However, is the testsuite the only use case? 

There's already been calls for a TimeService or ClockService as indicated by Sanne, here's one of the discussion threads:
http://lists.jboss.org/pipermail/infinispan-dev/2013-January/011933.html

I like the ClockService name better :)

> 
> 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()
> 
> //return the duration between now() and the startNanos/Millis
> long durationNanos(long startNanos)
> long durationMillis(long startMillis)
> 
> //return the duration between start+ and end+
> long durationNanos(long startNanos, long endNanos)
> long durationMillis(long startMillis, long endMillis)
> 
> Any other method? Maybe adding a TimeUnit parameter instead of duplicate 
> methods (e.g. now(TimeUnit))? Maybe some convert() with double 
> precision, since the TimeUnit.convert(...) usually loses precision?
> 
> (I need double precision for the Extended Statistics, but I can put this 
> converters in my classes)

^ Can you explain the use cases for each of these methods? 

Why do you need double precision for extended statistics? And what are these extended statistics? Have they been discussed in the dev list?

> 
> * Scope:
> 
> Should the TimeService be in a cache or global scope? My vote is per 
> cache…

^ My feeling is that it should be global. Why per cache?

> 
> * 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.

Hmmm, -1. As Manik said in another paralell discussion, we should separate between what really makes sense to be configured from a user perspective, and what we might wanna swap for testing.

> 
> 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


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org