[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