Right. And I muddied the waters, as I missed these classes were test
code only...
Sorry about this! Shouldn't read code at conferences ;-) Anyways, glad
to see that issue doesn't apply to any production code !
On Fri, Apr 27, 2012 at 10:34 AM, Steve Ebersole wrote:
> I guess the confusion was tha
I guess the confusion was that I never read anywhere that your solution
involved retrofitting your Timestamper class. I just read that as you
meant code should move to use this new SlewClock instead of
Timestamper. The hibernate-ehcache integration uses
net.sf.ehcache.util.Timestamper, so if
Well but we still have the issue of the hibernate-ehcache integration
using net.sf.ehcache.util.Timestamper. And we cannot use your
SlewClock there because it is package-protected.
On Fri 27 Apr 2012 09:05:56 AM CDT, Alex Snaps wrote:
> Right! I see these are all in the hibernate-testing code.
Well, to be specific I am not seeing it in 2.4.3 version of ehcache-core
jar (which is jar where Timestamper was found)...
On Fri 27 Apr 2012 08:37:53 AM CDT, Steve Ebersole wrote:
>
> Alex, the issue you mentioned says it was fixed for 2.4.3, but I am
> not seeing SlewClock in 2.4.3 jar.
>
> Wha
Alex, the issue you mentioned says it was fixed for 2.4.3, but I am not
seeing SlewClock in 2.4.3 jar.
What version was SlewClock added in?
On Fri 27 Apr 2012 08:36:33 AM CDT, Steve Ebersole wrote:
>
> Alex, the issue you mentioned says it was fixed for 2.4.3, but I am
> not seeing SlewClock in
Thanks for the heads up Alex.
https://hibernate.onjira.com/browse/HHH-7282
On Thu 26 Apr 2012 11:11:36 AM CDT, Alex Snaps wrote:
> Hey,
> I wanted to draw your attention to "an issue" we've hit with the
> nonblocking implementation of Timestamper, that you guys use as well.
> Basically, if time
Well you have the same issue with nanoTime(), beyond the fact that you
can't really trust it.
Also, there is no guarantee (iirc) for it to return consistent values
across cores, so it could go backwards.
Also, from a distributed caching perspective, this gives "some" sync
across multiple nodes.
(s
Would it be possible to use System.nanoTime() instead?
It's not suited to retrieve the absolute time (read the clock) but is
very efficient to measure time intervals, and never goes back in time.
Cheers,
Sanne
On 26 April 2012 17:11, Alex Snaps wrote:
> Hey,
> I wanted to draw your attention to
Hey,
I wanted to draw your attention to "an issue" we've hit with the
nonblocking implementation of Timestamper, that you guys use as well.
Basically, if time goes backwards, calling next() would loop until
time is passed the last seen value (see
http://jira.terracotta.org/jira/browse/EHC-853)
Tech
