[infinispan-dev] [Discussion] TimeService implementation

Mircea Markus mmarkus at redhat.com
Thu May 2 15:13:06 EDT 2013


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

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list