[infinispan-dev] [Discussion] TimeService implementation

Thu May 2 08:42:15 EDT 2013

See below for comments:

On May 1, 2013, at 4:13 PM, Pedro Ruivo <pedro at infinispan.org> wrote:

> Hi Galder,
> 
> On 05/01/2013 08:43 AM, Galder Zamarreño wrote:
>> 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
> 
> thanks for the link :)
> 
>> 
>> 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?
> 
> I haven't discussed the Extended Statistic in the mailling list because 
> it was discussed between Mircea, Manik, Paolo and me (it will be ported 
> from the Cloud-TM project). However, a JIRA already exists for it:
> 
> https://issues.jboss.org/browse/ISPN-2861
> 
> The double precision is needed, for example, for the transaction arrival 
> rate (total number of transactions committed divide by the duration 
> since last statistic reset). The arrival rate is calculated in tx/sec 
> and if I'm going to convert nanoseconds to seconds, in the first second 
> the arrival rate is NaN. The same for throughput.
> 
> I took a look in the mails from the mailling list and I think the 
> caching the value will be prejudicial for the Extended Statistics. 
> However, I think it can work to expire the cache entries.

^ Indeed, that's why I wanted to open up the discussion to the topic in that thread, because it'd be good to come up with a timer/clock service that works for both use cases, or have different APIs, interfaces, or implementations based on the precision required, the need for multiple time unit supports (or not)…etc.

> Also, I think a method like boolean isExpired(long timestamp) is useful 
> to add to the interface.
> 
>> 
>>> 
>>> * 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?
> 
> When recovery is enabled, the recovery manager creates a second cache. 
> Someone may want to replace the Clock/TimeService for the "normal" cache 
> and left the default implementation in the "recovery" cache.

^ Why would an end-user want to replace the Clock/TimeService?

Remember what I said in my previous email: I can see someone changing the service implementation for testing reasons, and in that case, a global clock/timer service that's swapable via system property would work just fine IMO.

> 
>> 
>>> 
>>> * 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.
>> 
> 
> My 2cents, we only allow to be configured if we use some caching 
> approach to configure the update interval, or to disable it.

The two use cases I see for the clock/time service are:
- statistics
- expiration calculation

The former is already controlled by configuration, and the latter depends on whether expiration is enabled globally (i.e. global lifespan or maxIdle) or by having the user call a put call with lifespan/maxIdle.

If no stats are enabled, no global expiration is configured, and there's no user calls to cache with lifespan/maxIdle, inherently, the clock service won't be used. So, I don't see disabling the clock service something the user should have to worry about.

Not sure what the update interval. Also, what is the reason why a end-user might want to change it?

Finally, remember that keeping the service global has the benefit of consuming less resources, particularly in environments with a lot of caches.

Cheers,

> 
>>> 
>>> 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
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
> _______________________________________________
> 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