Re: [infinispan-dev] [Discussion] TimeService implementation

^ 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> -- >> Galder Zamarreño >> galder(a)redhat.com >> twitter.com/galderz >> >> Project Lead, Escalante >> http://escalante.io >> >> Engineer, Infinispan >> http://infinispan.org >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño galder(a)redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev