[ http://issues.datanucleus.org/browse/NUCCORE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cyril Bouteille updated NUCCORE-1053:
-------------------------------------
Attachment: datanucleus-l2-issue.tgz
Test case showing L2 GET for JDO class cacheable=false
(org.datanucleus.test.Main.main()) DEBUG [DataNucleus.Cache] - Object with id "org.datanucleus.test.order.PayOrder:1" not found in Level 2 cache
> Unexpected L2 cache look-ups for JDO with cacheable=false
> ---------------------------------------------------------
>
> Key: NUCCORE-1053
> URL: http://issues.datanucleus.org/browse/NUCCORE-1053
> Project: DataNucleus Core
> Issue Type: Bug
> Components: Cache
> Affects Versions: 3.2.4
> Environment: JDK 1.7
> RHEL
> Reporter: Cyril Bouteille
> Attachments: datanucleus-l2-issue.tgz
>
>
> We're experiencing bottlenecks in our performance testing which we narrowed down the lock wait in xmemcached plugin.
> We tried switching to spymemcached, but it didn't make a significant difference.
> Upon further investigation we uncovered an unexpectedly large amount of L2 cache activity, most of which are for JDO classes which are marked as cacheable=false in the metadata.
> It looks like the cache puts are guarded by cacheable=false, but not the gets.
> If this is not intended or otherwise necessary, could the code be optimized to assume a cache miss if the class is not cacheable?
> Thanks.
> We made a test case we will be uploading.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.datanucleus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Thread view

Unexpected L2 cache look-ups for JDO with cacheable=false
---------------------------------------------------------
Key: NUCCORE-1053
URL: http://issues.datanucleus.org/browse/NUCCORE-1053
Project: DataNucleus Core
Issue Type: Bug
Components: Cache
Affects Versions: 3.2.4
Environment: JDK 1.7
RHEL
Reporter: Cyril Bouteille
We're experiencing bottlenecks in our performance testing which we narrowed down the lock wait in xmemcached plugin.
We tried switching to spymemcached, but it didn't make a significant difference.
Upon further investigation we uncovered an unexpectedly large amount of L2 cache activity, most of which are for JDO classes which are marked as cacheable=false in the metadata.
It looks like the cache puts are guarded by cacheable=false, but not the gets.
If this is not intended or otherwise necessary, could the code be optimized to assume a cache miss if the class is not cacheable?
Thanks.
We made a test case we will be uploading.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.datanucleus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://issues.datanucleus.org/browse/NUCCORE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cyril Bouteille updated NUCCORE-1053:
-------------------------------------
Attachment: datanucleus-l2-issue.tgz
Test case showing L2 GET for JDO class cacheable=false
(org.datanucleus.test.Main.main()) DEBUG [DataNucleus.Cache] - Object with id "org.datanucleus.test.order.PayOrder:1" not found in Level 2 cache
> Unexpected L2 cache look-ups for JDO with cacheable=false
> ---------------------------------------------------------
>
> Key: NUCCORE-1053
> URL: http://issues.datanucleus.org/browse/NUCCORE-1053
> Project: DataNucleus Core
> Issue Type: Bug
> Components: Cache
> Affects Versions: 3.2.4
> Environment: JDK 1.7
> RHEL
> Reporter: Cyril Bouteille
> Attachments: datanucleus-l2-issue.tgz
>
>
> We're experiencing bottlenecks in our performance testing which we narrowed down the lock wait in xmemcached plugin.
> We tried switching to spymemcached, but it didn't make a significant difference.
> Upon further investigation we uncovered an unexpectedly large amount of L2 cache activity, most of which are for JDO classes which are marked as cacheable=false in the metadata.
> It looks like the cache puts are guarded by cacheable=false, but not the gets.
> If this is not intended or otherwise necessary, could the code be optimized to assume a cache miss if the class is not cacheable?
> Thanks.
> We made a test case we will be uploading.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.datanucleus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://issues.datanucleus.org/browse/NUCCORE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21097#action_21097 ]
Andy Jefferson commented on NUCCORE-1053:
-----------------------------------------
Yes, all it does currently is stop uncacheable things getting in the L2 cache. You could easily enough provide a patch to add checks on the get(s), attach it to this issue. Suggest that your patch gets the class name from the object id for OID/SingleFieldIdentity cases and checks that class name (nucCtx.isClassCacheable).
> Unexpected L2 cache look-ups for JDO with cacheable=false
> ---------------------------------------------------------
>
> Key: NUCCORE-1053
> URL: http://issues.datanucleus.org/browse/NUCCORE-1053
> Project: DataNucleus Core
> Issue Type: Bug
> Components: Cache
> Affects Versions: 3.2.4
> Environment: JDK 1.7
> RHEL
> Reporter: Cyril Bouteille
> Attachments: datanucleus-l2-issue.tgz
>
>
> We're experiencing bottlenecks in our performance testing which we narrowed down the lock wait in xmemcached plugin.
> We tried switching to spymemcached, but it didn't make a significant difference.
> Upon further investigation we uncovered an unexpectedly large amount of L2 cache activity, most of which are for JDO classes which are marked as cacheable=false in the metadata.
> It looks like the cache puts are guarded by cacheable=false, but not the gets.
> If this is not intended or otherwise necessary, could the code be optimized to assume a cache miss if the class is not cacheable?
> Thanks.
> We made a test case we will be uploading.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.datanucleus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://issues.datanucleus.org/browse/NUCCORE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cyril Bouteille updated NUCCORE-1053:
-------------------------------------
Attachment: ExecutionContextImpl.java
Attaching the patched file if preferable over the diff.
> Unexpected L2 cache look-ups for JDO with cacheable=false
> ---------------------------------------------------------
>
> Key: NUCCORE-1053
> URL: http://issues.datanucleus.org/browse/NUCCORE-1053
> Project: DataNucleus Core
> Issue Type: Bug
> Components: Cache
> Affects Versions: 3.2.4
> Environment: JDK 1.7
> RHEL
> Reporter: Cyril Bouteille
> Attachments: datanucleus-l2-issue.tgz, ExecutionContextImpl.java
>
>
> We're experiencing bottlenecks in our performance testing which we narrowed down the lock wait in xmemcached plugin.
> We tried switching to spymemcached, but it didn't make a significant difference.
> Upon further investigation we uncovered an unexpectedly large amount of L2 cache activity, most of which are for JDO classes which are marked as cacheable=false in the metadata.
> It looks like the cache puts are guarded by cacheable=false, but not the gets.
> If this is not intended or otherwise necessary, could the code be optimized to assume a cache miss if the class is not cacheable?
> Thanks.
> We made a test case we will be uploading.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.datanucleus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://issues.datanucleus.org/browse/NUCCORE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21103#action_21103 ]
Andy Jefferson commented on NUCCORE-1053:
-----------------------------------------
1. patch is the preferred format for anything, as per the docs.
2. your proposal means that someone who wants to have compound identity or composite identity will fail on anything. If an id is not OID or SingleFieldIdentity then you should ASSUME it is cacheable. This patch is (should be) an optimisation for the OID and SingleFieldIdentity cases to not go near the cache.
3. When you have a patch, please comment on whether that works for your case(s).
> Unexpected L2 cache look-ups for JDO with cacheable=false
> ---------------------------------------------------------
>
> Key: NUCCORE-1053
> URL: http://issues.datanucleus.org/browse/NUCCORE-1053
> Project: DataNucleus Core
> Issue Type: Bug
> Components: Cache
> Affects Versions: 3.2.4
> Environment: JDK 1.7
> RHEL
> Reporter: Cyril Bouteille
> Attachments: datanucleus-l2-issue.tgz, ExecutionContextImpl.java
>
>
> We're experiencing bottlenecks in our performance testing which we narrowed down the lock wait in xmemcached plugin.
> We tried switching to spymemcached, but it didn't make a significant difference.
> Upon further investigation we uncovered an unexpectedly large amount of L2 cache activity, most of which are for JDO classes which are marked as cacheable=false in the metadata.
> It looks like the cache puts are guarded by cacheable=false, but not the gets.
> If this is not intended or otherwise necessary, could the code be optimized to assume a cache miss if the class is not cacheable?
> Thanks.
> We made a test case we will be uploading.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.datanucleus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://issues.datanucleus.org/browse/NUCCORE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21105#action_21105 ]
Andy Jefferson commented on NUCCORE-1053:
-----------------------------------------
I added a variation on your code to SVN trunk, NucleusContext.isClassWithIdentityCacheable and a call to it from ExecutionContext. Causes no problems with DN tests, JDO TCK or JPA TCK. Report back if it works on your cases.
One potential problem is the composite PK case if the first of the classes with the PK class is not cacheable yet others are, but then that's a minority use-case.
> Unexpected L2 cache look-ups for JDO with cacheable=false
> ---------------------------------------------------------
>
> Key: NUCCORE-1053
> URL: http://issues.datanucleus.org/browse/NUCCORE-1053
> Project: DataNucleus Core
> Issue Type: Bug
> Components: Cache
> Affects Versions: 3.2.4
> Environment: JDK 1.7
> RHEL
> Reporter: Cyril Bouteille
> Attachments: datanucleus-l2-issue.tgz, ExecutionContextImpl.java
>
>
> We're experiencing bottlenecks in our performance testing which we narrowed down the lock wait in xmemcached plugin.
> We tried switching to spymemcached, but it didn't make a significant difference.
> Upon further investigation we uncovered an unexpectedly large amount of L2 cache activity, most of which are for JDO classes which are marked as cacheable=false in the metadata.
> It looks like the cache puts are guarded by cacheable=false, but not the gets.
> If this is not intended or otherwise necessary, could the code be optimized to assume a cache miss if the class is not cacheable?
> Thanks.
> We made a test case we will be uploading.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.datanucleus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://issues.datanucleus.org/browse/NUCCORE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21107#action_21107 ]
Cyril Bouteille commented on NUCCORE-1053:
------------------------------------------
Great, thanks!
I don't have the whole env to build trunk, but I backported http://sourceforge.net/p/datanucleus/code/17616/ to 3.2.4, patched datanucleus-core-3.2.4.jar and verified it works as well in our app env.
Please let us know which version you plan to target this fix for.
Thank you
Cyril
> Unexpected L2 cache look-ups for JDO with cacheable=false
> ---------------------------------------------------------
>
> Key: NUCCORE-1053
> URL: http://issues.datanucleus.org/browse/NUCCORE-1053
> Project: DataNucleus Core
> Issue Type: Bug
> Components: Cache
> Affects Versions: 3.2.4
> Environment: JDK 1.7
> RHEL
> Reporter: Cyril Bouteille
> Attachments: datanucleus-l2-issue.tgz, ExecutionContextImpl.java
>
>
> We're experiencing bottlenecks in our performance testing which we narrowed down the lock wait in xmemcached plugin.
> We tried switching to spymemcached, but it didn't make a significant difference.
> Upon further investigation we uncovered an unexpectedly large amount of L2 cache activity, most of which are for JDO classes which are marked as cacheable=false in the metadata.
> It looks like the cache puts are guarded by cacheable=false, but not the gets.
> If this is not intended or otherwise necessary, could the code be optimized to assume a cache miss if the class is not cacheable?
> Thanks.
> We made a test case we will be uploading.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.datanucleus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://issues.datanucleus.org/browse/NUCCORE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Jefferson resolved NUCCORE-1053.
-------------------------------------
Fix Version/s: 3.2.5
Resolution: Fixed
I don't see a need to "build" anything, that's what nightly builds are and always have been (under Download on the website). This will be 3.2.5 of "datanucleus-core", which will be part of AccessPlatform 3.2.4 and 3.3.0-m2
> Unexpected L2 cache look-ups for JDO with cacheable=false
> ---------------------------------------------------------
>
> Key: NUCCORE-1053
> URL: http://issues.datanucleus.org/browse/NUCCORE-1053
> Project: DataNucleus Core
> Issue Type: Bug
> Components: Cache
> Affects Versions: 3.2.4
> Environment: JDK 1.7
> RHEL
> Reporter: Cyril Bouteille
> Fix For: 3.2.5
>
> Attachments: datanucleus-l2-issue.tgz, ExecutionContextImpl.java
>
>
> We're experiencing bottlenecks in our performance testing which we narrowed down the lock wait in xmemcached plugin.
> We tried switching to spymemcached, but it didn't make a significant difference.
> Upon further investigation we uncovered an unexpectedly large amount of L2 cache activity, most of which are for JDO classes which are marked as cacheable=false in the metadata.
> It looks like the cache puts are guarded by cacheable=false, but not the gets.
> If this is not intended or otherwise necessary, could the code be optimized to assume a cache miss if the class is not cacheable?
> Thanks.
> We made a test case we will be uploading.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.datanucleus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira