11:34 a.m.
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).
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)
* Scope:
Should the TimeService be in a cache or global scope? My vote is per
cache...
* 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.
Any other subject? Thoughts?
If I was not clear let me know...
Cheers,
Pedro Ruivo
11:53 a.m.
On 29 Apr 2013, at 17:34, Pedro Ruivo 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).
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()
What about time() and wallClockTime() with overloaded methods
time(TimeUnit) and wallClockTime(TimeUnit)?
//return the duration between now() and the startNanos/Millis
long durationNanos(long startNanos)
long durationMillis(long startMillis)
+1
//return the duration between start+ and end+
long durationNanos(long startNanos, long endNanos)
besides return (endNanos -
startNanos) does it do some sanity checks? if it's only for the difference i think the
subtraction is simpler
long durationMillis(long startMillis, long endMillis)
Any other method? Maybe adding a TimeUnit parameter instead of duplicate
methods (e.g. now(TimeUnit))?
both :-)
Maybe some convert() with double
precision, since the TimeUnit.convert(...) usually loses precision?
only when
moving from finer to coarser granularity, but that's to be expected.
(I need double precision for the Extended Statistics, but I can put this
converters in my classes)
* Scope:
Should the TimeService be in a cache or global scope? My vote is per
cache...
+1
* 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.
I liked your idea to inject it in the ComponentRegistry. Perhaps a
ComponentRegistry.setTimeService method?
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
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
12:04 p.m.
On 04/29/2013 05:53 PM, Mircea Markus wrote:
On 29 Apr 2013, at 17:34, Pedro Ruivo 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).
>
> 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()
What about time() and wallClockTime() with overloaded methods time(TimeUnit) and
wallClockTime(TimeUnit)?
what is the semantic of wallClockTime()? I'm assuming that time()
returns the current time in nanoseconds...
>
> //return the duration between now() and the startNanos/Millis
> long durationNanos(long startNanos)
> long durationMillis(long startMillis)
+1
>
> //return the duration between start+ and end+
> long durationNanos(long startNanos, long endNanos)
besides return (endNanos - startNanos) does it do some sanity checks? if it's only
for the difference i think the subtraction is simpler
yes, it should check if endNano >= startNanos. Also, I need it in the
test suite to return always 1 in order to predict the throughputs,
durations, waiting and holding times...
> long durationMillis(long startMillis, long endMillis)
>
> Any other method? Maybe adding a TimeUnit parameter instead of duplicate
> methods (e.g. now(TimeUnit))?
both :-)
> Maybe some convert() with double
> precision, since the TimeUnit.convert(...) usually loses precision?
only when moving from finer to coarser granularity, but that's to be expected.
I like to be precise :D
>
> (I need double precision for the Extended Statistics, but I can put this
> converters in my classes)
>
> * Scope:
>
> Should the TimeService be in a cache or global scope? My vote is per
> cache...
+1
>
> * 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.
I liked your idea to inject it in the ComponentRegistry. Perhaps a
ComponentRegistry.setTimeService method?
I think that is better to register the DefaultTimeService and if the
user wants to overwrite (i.e. us in the test suite), he can use
ComponentRegistry.replaceTimeService(). The last method will register
and rewire the component registry
>
> 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
Cheers,
10:04 a.m.
On 29 April 2013 18:04, Pedro Ruivo <pedro(a)infinispan.org> wrote:
On 04/29/2013 05:53 PM, Mircea Markus wrote:
>
> On 29 Apr 2013, at 17:34, Pedro Ruivo 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).
>>
>> 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()
> What about time() and wallClockTime() with overloaded methods time(TimeUnit) and
wallClockTime(TimeUnit)?
what is the semantic of wallClockTime()? I'm assuming that time()
returns the current time in nanoseconds...
There are at least two ways to use a Clock service, as there are
different methods to get the "time" and different concepts of "time"
depending on what your purpose is.
For example you should never use two invocations of
System.currentTimeMillis() to measure time intervals; it's generally
less accurate but also it is affected by system clock changes, while
nanoTime() is not. The underlying system calls are different, and
depending on the platform the precision guarantees are different and
in some cases the different precision guarantee has a significant
impact on runtime performance of the invocation, for example not all
can be JIT optimized.
Most of the time we want to use nanoTime(), for example for metrics,
but its precision is valid only in the scope of the machine it's
executed on, so this value is meaningless for something which needs to
be shared with other nodes.. complex, and we might want to switch
implementation for certain use cases depending on the cluster mode.
In other words: the method invoker needs to make it very clear what
its goal is, what it wants to do with the requested "long" as it's not
just a simple universally valid primitive.
6:49 a.m.
On 1 May 2013, at 16:04, Sanne Grinovero wrote:
>>> 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).
>>>
>>> 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()
>> What about time() and wallClockTime() with overloaded methods time(TimeUnit) and
wallClockTime(TimeUnit)?
>
> what is the semantic of wallClockTime()? I'm assuming that time()
> returns the current time in nanoseconds...
There are at least two ways to use a Clock service, as there are
different methods to get the "time" and different concepts of "time"
depending on what your purpose is.
For example you should never use two invocations of
System.currentTimeMillis() to measure time intervals; it's generally
less accurate but also it is affected by system clock changes, while
nanoTime() is not. The underlying system calls are different, and
depending on the platform the precision guarantees are different and
in some cases the different precision guarantee has a significant
impact on runtime performance of the invocation, for example not all
can be JIT optimized.
Most of the time we want to use nanoTime(), for example for metrics,
but its precision is valid only in the scope of the machine it's
executed on, so this value is meaningless for something which needs to
be shared with other nodes.. complex, and we might want to switch
implementation for certain use cases depending on the cluster mode.
In other words: the method invoker needs to make it very clear what
its goal is, what it wants to do with the requested "long" as it's not
just a simple universally valid primitive.
Thanks for the very nice explanation
Sanne.
So as a rule:
- use nanoTime for measuring duration on the same JVM (time() method mentioned below)
- currentTimeMillis for the wall-clock (wallClockTime() method)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
7:44 a.m.
On May 1, 2013, at 5:04 PM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 29 April 2013 18:04, Pedro Ruivo <pedro(a)infinispan.org>
wrote:
>
> On 04/29/2013 05:53 PM, Mircea Markus wrote:
>>
>> On 29 Apr 2013, at 17:34, Pedro Ruivo 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).
>>>
>>> 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()
>> What about time() and wallClockTime() with overloaded methods time(TimeUnit) and
wallClockTime(TimeUnit)?
>
> what is the semantic of wallClockTime()? I'm assuming that time()
> returns the current time in nanoseconds...
There are at least two ways to use a Clock service, as there are
different methods to get the "time" and different concepts of "time"
depending on what your purpose is.
For example you should never use two invocations of
System.currentTimeMillis() to measure time intervals; it's generally
less accurate but also it is affected by system clock changes, while
nanoTime() is not. The underlying system calls are different, and
depending on the platform the precision guarantees are different and
in some cases the different precision guarantee has a significant
impact on runtime performance of the invocation, for example not all
can be JIT optimized.
Most of the time we want to use nanoTime(), for example for metrics,
but its precision is valid only in the scope of the machine it's
executed on, so this value is meaningless for something which needs to
be shared with other nodes.. complex, and we might want to switch
implementation for certain use cases depending on the cluster mode.
^ Can you explain further why you'd want a different implementation depending on the
cluster mode?
In other words: the method invoker needs to make it very clear what
its goal is, what it wants to do with the requested "long" as it's not
just a simple universally valid primitive.
_______________________________________________
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
2:43 a.m.
Hi Pedro,
On Apr 29, 2013, at 6:34 PM, Pedro Ruivo <pedro(a)infinispan.org> 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
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?
* 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?
* 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.
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
9:13 a.m.
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 <pedro(a)infinispan.org> 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.
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.
>
> * 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.
>
> 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
7:42 a.m.
See below for comments:
On May 1, 2013, at 4:13 PM, Pedro Ruivo <pedro(a)infinispan.org> 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 <pedro(a)infinispan.org> 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
>> 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
1:01 p.m.
See inline...
On 05/02/2013 01:42 PM, Galder Zamarreño wrote:
See below for comments:
On May 1, 2013, at 4:13 PM, Pedro Ruivo <pedro(a)infinispan.org> 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 <pedro(a)infinispan.org> 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.
+1
I believe that the statistics measure needs to be precise. The entries
expiration and the timeouts (see below), can be imprecise (i.e. the
values can be cached).
About the implementation I'm not sure what is better. A single interface
with precise and imprecise? or two implementations of a single interface?
the first one has the advantage of the imprecise values may be more
precise. example:
preciseTime() {return (cached = System.nanoTime());}
impreciseTime() {return cached;}
> 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.
I don't know. I'm being pessimist and assuming that someone in the world
as a dark use case and needs to replace the service.
Looking at the code, it is easiest for me to use a global service :)
>
>>
>>>
>>> * 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
another Clock/TimeService is in timeouts (locking, tasks, etc...)
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?
the obvious example is the locking timeout. If we have 1 sec update
interval, and the user configures the locking timeout to 100ms, having 1
sec in the update interval may have a huge impact in the performance.
Finally, remember that keeping the service global has the benefit of consuming less
resources, particularly in environments with a lot of caches.
+1
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
5:46 a.m.
On May 2, 2013, at 7:01 PM, Pedro Ruivo <pedro(a)infinispan.org> wrote:
>> 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.
I don't know. I'm being pessimist and assuming that someone in the world
as a dark use case and needs to replace the service.
^ We already have quite a big configuration… we should think twice about adding more
stuff… :)
Cheers,
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
6:51 a.m.
On 3 May 2013, at 11:46, Galder Zamarreño wrote:
On May 2, 2013, at 7:01 PM, Pedro Ruivo <pedro(a)infinispan.org>
wrote:
>>> 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.
>
> I don't know. I'm being pessimist and assuming that someone in the world
> as a dark use case and needs to replace the service.
^ We already have quite a big configuration… we should think twice about adding more
stuff… :)
+1. on top of that we can always add it to config if needed, harder to
remove it.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
6:58 a.m.
For testing purposes it would be useful to inject a custom
implementation. Doesn't have to be a public API, but some kind of
extension point would be needed.
On 3 May 2013 12:51, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 3 May 2013, at 11:46, Galder Zamarreño wrote:
> On May 2, 2013, at 7:01 PM, Pedro Ruivo <pedro(a)infinispan.org> wrote:
>
>>>> 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.
>>
>> I don't know. I'm being pessimist and assuming that someone in the world
>> as a dark use case and needs to replace the service.
>
> ^ We already have quite a big configuration… we should think twice about adding more
stuff… :)
+1. on top of that we can always add it to config if needed, harder to remove it.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:48 a.m.
Because of the component registry, every component is a (non-public)
extension point by itself. So I don't see the need to do anything special,
if we're only going to use it in the test suite.
On Fri, May 3, 2013 at 2:58 PM, Sanne Grinovero <sanne(a)infinispan.org>wrote:
For testing purposes it would be useful to inject a custom
implementation. Doesn't have to be a public API, but some kind of
extension point would be needed.
On 3 May 2013 12:51, Mircea Markus <mmarkus(a)redhat.com> wrote:
>
> On 3 May 2013, at 11:46, Galder Zamarreño wrote:
>
>> On May 2, 2013, at 7:01 PM, Pedro Ruivo <pedro(a)infinispan.org> wrote:
>>
>>>>> 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.
>>>
>>> I don't know. I'm being pessimist and assuming that someone in the
world
>>> as a dark use case and needs to replace the service.
>>
>> ^ We already have quite a big configuration… we should think twice
about adding more stuff… :)
> +1. on top of that we can always add it to config if needed, harder to
remove it.
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.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
10:49 a.m.
On 2 May 2013, at 19:01, Pedro Ruivo <pedro(a)infinispan.org> wrote:
preciseTime() {return (cached = System.nanoTime());}
impreciseTime() {return cached;}
How would you invalidate the cached time?
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.
I don't know. I'm being pessimist and assuming that someone in the world
as a dark use case and needs to replace the service.
Looking at the code, it is easiest for me to use a global service :)
+1 to a global service.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
10:54 a.m.
On 05/03/2013 04:49 PM, Manik Surtani wrote:
On 2 May 2013, at 19:01, Pedro Ruivo <pedro(a)infinispan.org> wrote:
>
> preciseTime() {return (cached = System.nanoTime());}
> impreciseTime() {return cached;}
How would you invalidate the cached time?
My idea is to have a schedule thread updating the cached time. the
preciseTime() is just an optimization to keep the cached value more
up-to-date since we are calculating the nanoTime() (and assuming that
nanoTime() is more expensive than write in the volatile variable).
> 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.
>
> I don't know. I'm being pessimist and assuming that someone in the world
> as a dark use case and needs to replace the service.
>
> Looking at the code, it is easiest for me to use a global service :)
+1 to a global service.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11 a.m.
On 3 May 2013, at 16:54, Pedro Ruivo wrote:
On 05/03/2013 04:49 PM, Manik Surtani wrote:
>
> On 2 May 2013, at 19:01, Pedro Ruivo <pedro(a)infinispan.org> wrote:
>
>>
>> preciseTime() {return (cached = System.nanoTime());}
>> impreciseTime() {return cached;}
>
> How would you invalidate the cached time?
My idea is to have a schedule thread updating the cached time. the
preciseTime() is just an optimization to keep the cached value more
up-to-date since we are calculating the nanoTime() (and assuming that
nanoTime() is more expensive than write in the volatile variable).
Sounds like a good idea but please don't implement that for now. That's a
performance optimisation and would require benchmarking to prove it's worth doing -
more of a nice to have ATM.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
6:46 a.m.
On Fri, May 3, 2013 at 7:00 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 3 May 2013, at 16:54, Pedro Ruivo wrote:
> On 05/03/2013 04:49 PM, Manik Surtani wrote:
>>
>> On 2 May 2013, at 19:01, Pedro Ruivo <pedro(a)infinispan.org> wrote:
>>
>>>
>>> preciseTime() {return (cached = System.nanoTime());}
>>> impreciseTime() {return cached;}
>>
>> How would you invalidate the cached time?
>
> My idea is to have a schedule thread updating the cached time. the
> preciseTime() is just an optimization to keep the cached value more
> up-to-date since we are calculating the nanoTime() (and assuming that
> nanoTime() is more expensive than write in the volatile variable).
Sounds like a good idea but please don't implement that for now. That's a
performance optimisation and would require benchmarking to prove it's worth
doing - more of a nice to have ATM.
Actually, the performance optimization would be not to write the cached
time in preciseTime would be the performance optimization.
6:08 a.m.
On 4 May 2013, at 12:46, Dan Berindei wrote:
On Fri, May 3, 2013 at 7:00 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 3 May 2013, at 16:54, Pedro Ruivo wrote:
> On 05/03/2013 04:49 PM, Manik Surtani wrote:
>>
>> On 2 May 2013, at 19:01, Pedro Ruivo <pedro(a)infinispan.org> wrote:
>>
>>>
>>> preciseTime() {return (cached = System.nanoTime());}
>>> impreciseTime() {return cached;}
>>
>> How would you invalidate the cached time?
>
> My idea is to have a schedule thread updating the cached time. the
> preciseTime() is just an optimization to keep the cached value more
> up-to-date since we are calculating the nanoTime() (and assuming that
> nanoTime() is more expensive than write in the volatile variable).
Sounds like a good idea but please don't implement that for now. That's a
performance optimisation and would require benchmarking to prove it's worth doing -
more of a nice to have ATM.
Actually, the performance optimization would be not to write the cached time in
preciseTime would be the performance optimization.
I mean don't use time caching for now.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
6:47 a.m.
On 3 May 2013, at 17:00, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 3 May 2013, at 16:54, Pedro Ruivo wrote:
> On 05/03/2013 04:49 PM, Manik Surtani wrote:
>>
>> On 2 May 2013, at 19:01, Pedro Ruivo <pedro(a)infinispan.org> wrote:
>>
>>>
>>> preciseTime() {return (cached = System.nanoTime());}
>>> impreciseTime() {return cached;}
>>
>> How would you invalidate the cached time?
>
> My idea is to have a schedule thread updating the cached time. the
> preciseTime() is just an optimization to keep the cached value more
> up-to-date since we are calculating the nanoTime() (and assuming that
> nanoTime() is more expensive than write in the volatile variable).
Sounds like a good idea but please don't implement that for now. That's a
performance optimisation and would require benchmarking to prove it's worth doing
Exactly. You may well find that this is what the JDK does anyway. Plus the cost of a
scheduled thread (context switching, volatile write, etc) may not really be worth the
perceived benefits.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
10:54 a.m.
On 3 May 2013, at 16:49, Manik Surtani wrote:
On 2 May 2013, at 19:01, Pedro Ruivo <pedro(a)infinispan.org>
wrote:
>
> preciseTime() {return (cached = System.nanoTime());}
> impreciseTime() {return cached;}
How would you invalidate the cached time?
update the cache value async every X
millis would be one way to do it.
As a note, we shouldn't focus on caching the time for now but just use the service in
order to be able to unit test time related issues.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
2:13 p.m.
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(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
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
6:50 a.m.
On 1 May 2013, at 08:43, Galder Zamarreño wrote:
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
I like the ClockService name better :)
TimeService sounds more generic to me, as System.nanoTime doesn't involve any clock.
Either would do though :-)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
9:42 a.m.
Hi all,
I've made a pull request with the TimeService implementation [1]. Anyone
interested can take a look and give me some feedback about it and if it
fills your requirements.
Currently, it only has one implementation that wraps the
System.nanoTime() and System.currentTimeMillis() invocation without any
optimization or cached values.
Cheers,
Pedro
On 04/29/2013 05:34 PM, Pedro Ruivo 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).
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)
* Scope:
Should the TimeService be in a cache or global scope? My vote is per
cache...
* 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.
Any other subject? Thoughts?
If I was not clear let me know...
Cheers,
Pedro Ruivo
4014
days inactive
4024
days old
infinispan-dev@lists.jboss.org
23 comments
6 participants
participants (6)
-
Dan Berindei -
Galder Zamarreño -
Manik Surtani -
Mircea Markus -
Pedro Ruivo -
Sanne Grinovero