On 2 May 2013, at 13:42, Galder Zamarreño wrote: > > ^ 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. System properties are not a good way to manage the time service because of the parallel test suite. As Pedro suggested in another conversation, I think the best place to set this is the ComponentRegistry. >>>> >>>> * 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. I think we shouldn't' allow users to configure the time service at all, at least until there's community/user demand for that.
>>> >> >> 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. +1. The main reason ATM for having an time service is for being able to test statistics and write predictable tests for expiration. Cacheing the time (!!) is a nice to have. > > 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. +1. If we'll need to move it to a cache level we can do that, as it won't be exposed to the users > > 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 Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
