See below for comments: On May 1, 2013, at 4:13 PM, Pedro Ruivo <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> -- >> Galder Zamarreño >> [email protected] >> twitter.com/galderz >> >> Project Lead, Escalante >> http://escalante.io >> >> Engineer, Infinispan >> http://infinispan.org >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
