Investigate 2L misses for listing pairs in domain
Reported by Ben Hood | September 26th, 2011 @ 08:02 PM
Querying for all pairs in a domain appears to cause cache misses - we should find out why this is happening.
#367 introduced a workaround for this - part of solving this ticket must be to unwind the changes in that ticket, i.e. delete the PairCache class.
Comments and changes to this ticket
-
Ben Hood September 26th, 2011 @ 08:04 PM
(from [489d577925b63107720a512e23f2aa1272395974]) [#366] Added test to replicate caching issue https://github.com/lshift/diffa/commit/489d577925b63107720a512e23f2...
-
Ben Hood September 26th, 2011 @ 08:06 PM
- State changed from “new” to “open”
I've done some preliminary investigation with this and it appears as if caching starts to take effect after ca. 120K queries. I don't however know why it takes so long for the cache to kick in.
-
Ben Hood September 26th, 2011 @ 11:33 PM
I've just tested this on OSX 10.7.1 / java version "1.6.0_26" and get the same behavior, albeit at around 160K - surely this is not a JIT issue?
-
Paul Jones September 26th, 2011 @ 11:39 PM
It looks to be a Hibernate issue - I put it to two reps only, and turned on
full hibernate debugging. The last update timestamps it is using a skewed.
At the start of the call it lists one last-update time, and then at the end
it caches it with an older one, hence meaning the next iteration is doomed
to fail. I haven't yet attempted to see what the change is after the 100k
iteration. -
Ben Hood September 26th, 2011 @ 11:49 PM
Interesting - could you post a snippet of the output that you are seeing? Which part of the API were you looking at?
I'm wondering whether it is worth creating a cut down version of this that can be used to verify that it is really is a Hibernate issue. If it turns out to be the case, this could be used to submit a ticket in their tracker.
Furthermore it would be good to know whether this is a patchable issue or whether we would have to code around it. I saw this whole behavior when I was looking into some performance issues and noticed that the call to listPairs/1 in the DomainConfigStore was taking up a significant amount of wall clock.
-
Ben Hood September 27th, 2011 @ 02:08 AM
Created a test case to reproduce this (https://github.com/0x6e6562/hibernate_2L) and a ticket with Hibernate to track this: https://hibernate.onjira.com/browse/HHH-6680
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
A Real Time Differencing Tool.
People watching this ticket
Ben Hood
Tags
Referenced by
-
366
Investigate 2L misses for listing pairs in domain
(from [489d577925b63107720a512e23f2aa1272395974])
[#366] ...
-
367
Workaround for 2L misses
In order to alleviate a hot spot that appears to be cause...
-
368
Optimize call to get all pairs in a domain
#367 introduced a short term cache-based
workaround for a...
-
384
Hand cache hibernate stores
Also look at #366