[infinispan-dev] [Discussion] TimeService implementation

Pedro Ruivo pedro at infinispan.org
Thu May 2 14:01:30 EDT 2013


See inline...

On 05/02/2013 01:42 PM, Galder Zamarreño wrote:
> 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.

+1

I believe that the statistics measure needs to be precise. The entries 
expiration and the timeouts (see below), can be imprecise (i.e. the 
values can be cached).

About the implementation I'm not sure what is better. A single interface 
with precise and imprecise? or two implementations of a single interface?

the first one has the advantage of the imprecise values may be more 
precise. example:

preciseTime() {return (cached = System.nanoTime());}
impreciseTime() {return cached;}


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

I don't know. I'm being pessimist and assuming that someone in the world 
as a dark use case and needs to replace the service.

Looking at the code, it is easiest for me to use a global service :)
>
>>
>>>
>>>>
>>>> * 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

another Clock/TimeService is in timeouts (locking, tasks, etc...)

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

the obvious example is the locking timeout. If we have 1 sec update 
interval, and the user configures the locking timeout to 100ms, having 1 
sec in the update interval may have a huge impact in the performance.

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

+1

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


More information about the infinispan-dev mailing list