Some more information. I'm running this test with JBossCache 1.1, but have also
tried the latest HEAD revision with the same results. Here's a stack trace from
1.1 that shows the loop.
| checkCacheConsistency():142, org.jboss.cache.aop.CacheInterceptor
| invoke():88, org.jboss.cache.aop.CacheInterceptor
| invokeNext():46, org.jboss.aop.joinpoint.FieldReadInvocation
| invokeRead():1679, org.jboss.aop.ClassAdvisor
| hashCode():40, IdObject
| hash():264, java.util.HashMap
| get():320, java.util.HashMap
| getChild():116, org.jboss.cache.Node
| findNode():3252, org.jboss.cache.TreeCache
| findNode():3344, org.jboss.cache.TreeCache
| _get():1571, org.jboss.cache.TreeCache
| invoke0():-1, sun.reflect.NativeMethodAccessorImpl
| invoke():39, sun.reflect.NativeMethodAccessorImpl
| invoke():25, sun.reflect.DelegatingMethodAccessorImpl
| invoke():585, java.lang.reflect.Method
| invoke():236, org.jgroups.blocks.MethodCall
| invoke():14, org.jboss.cache.interceptors.CallInterceptor
| invokeMethod():3181, org.jboss.cache.TreeCache
| get():1591, org.jboss.cache.TreeCache
| peek():1604, org.jboss.cache.TreeCache
| checkCacheConsistency():142, org.jboss.cache.aop.CacheInterceptor
| invoke():88, org.jboss.cache.aop.CacheInterceptor
| invokeNext():46, org.jboss.aop.joinpoint.FieldReadInvocation
| invokeRead():1679, org.jboss.aop.ClassAdvisor
| hashCode():40, IdObject
| hash():264, java.util.HashMap
| get():320, java.util.HashMap
| getChild():116, org.jboss.cache.Node
| findNode():3252, org.jboss.cache.TreeCache
| findNode():3344, org.jboss.cache.TreeCache
| _get():1571, org.jboss.cache.TreeCache
| invoke0():-1, sun.reflect.NativeMethodAccessorImpl
| invoke():39, sun.reflect.NativeMethodAccessorImpl
| invoke():25, sun.reflect.DelegatingMethodAccessorImpl
| invoke():585, java.lang.reflect.Method
| invoke():236, org.jgroups.blocks.MethodCall
| invoke():14, org.jboss.cache.interceptors.CallInterceptor
| invokeMethod():3181, org.jboss.cache.TreeCache
| get():1591, org.jboss.cache.TreeCache
| peek():1604, org.jboss.cache.TreeCache
| checkCacheConsistency():142, org.jboss.cache.aop.CacheInterceptor
| invoke():88, org.jboss.cache.aop.CacheInterceptor
| invokeNext():46, org.jboss.aop.joinpoint.FieldReadInvocation
| invokeRead():1679, org.jboss.aop.ClassAdvisor
| hashCode():40, IdObject
| hash():264, java.util.HashMap
| get():320, java.util.HashMap
| getChild():116, org.jboss.cache.Node
| findNode():3252, org.jboss.cache.TreeCache
| findNode():3344, org.jboss.cache.TreeCache
| _get():1571, org.jboss.cache.TreeCache
| invoke0():-1, sun.reflect.NativeMethodAccessorImpl
| invoke():39, sun.reflect.NativeMethodAccessorImpl
| invoke():25, sun.reflect.DelegatingMethodAccessorImpl
| invoke():585, java.lang.reflect.Method
| invoke():236, org.jgroups.blocks.MethodCall
| invoke():14, org.jboss.cache.interceptors.CallInterceptor
| invokeMethod():3181, org.jboss.cache.TreeCache
| get():1591, org.jboss.cache.TreeCache
| peek():1604, org.jboss.cache.TreeCache
| checkCacheConsistency():142, org.jboss.cache.aop.CacheInterceptor
| invoke():88, org.jboss.cache.aop.CacheInterceptor
| invokeNext():46, org.jboss.aop.joinpoint.FieldReadInvocation
| invokeRead():1679, org.jboss.aop.ClassAdvisor
| hashCode():40, IdObject
| hash():264, java.util.HashMap
| get():320, java.util.HashMap
| getChild():116, org.jboss.cache.Node
| findNode():3252, org.jboss.cache.TreeCache
| findNode():3344, org.jboss.cache.TreeCache
| _get():1571, org.jboss.cache.TreeCache
| invoke0():-1, sun.reflect.NativeMethodAccessorImpl
| invoke():39, sun.reflect.NativeMethodAccessorImpl
| invoke():25, sun.reflect.DelegatingMethodAccessorImpl
| invoke():585, java.lang.reflect.Method
| invoke():236, org.jgroups.blocks.MethodCall
| invoke():14, org.jboss.cache.interceptors.CallInterceptor
| invokeMethod():3181, org.jboss.cache.TreeCache
| get():1591, org.jboss.cache.TreeCache
| peek():1604, org.jboss.cache.TreeCache
| checkCacheConsistency():142, org.jboss.cache.aop.CacheInterceptor
| invoke():88, org.jboss.cache.aop.CacheInterceptor
| invokeNext():46, org.jboss.aop.joinpoint.FieldReadInvocation
| invokeRead():1679, org.jboss.aop.ClassAdvisor
| hashCode():40, IdObject
| hash():264, java.util.HashMap
| get():320, java.util.HashMap
| createChild():194, org.jboss.cache.Node
| findNode():3270, org.jboss.cache.TreeCache
| _put():2264, org.jboss.cache.TreeCache
| _put():2232, org.jboss.cache.TreeCache
| invoke0():-1, sun.reflect.NativeMethodAccessorImpl
| invoke():39, sun.reflect.NativeMethodAccessorImpl
| invoke():25, sun.reflect.DelegatingMethodAccessorImpl
| invoke():585, java.lang.reflect.Method
| invoke():236, org.jgroups.blocks.MethodCall
| invoke():14, org.jboss.cache.interceptors.CallInterceptor
| invokeMethod():3181, org.jboss.cache.TreeCache
| put():1709, org.jboss.cache.TreeCache
| _putObject():245, org.jboss.cache.aop.TreeCacheAop
| _putObject():240, org.jboss.cache.aop.TreeCacheAop
| putObject():132, org.jboss.cache.aop.TreeCacheAop
| put():70, org.jboss.cache.aop.CachedMapInterceptor
| invoke0():-1, sun.reflect.NativeMethodAccessorImpl
| invoke():39, sun.reflect.NativeMethodAccessorImpl
| invoke():25, sun.reflect.DelegatingMethodAccessorImpl
| invoke():585, java.lang.reflect.Method
| invoke():87, org.jboss.cache.aop.CollectionInterceptorUtil
| invoke():41, org.jboss.cache.aop.CachedMapInterceptor
| invokeNext():57, org.jboss.aop.joinpoint.MethodInvocation
| _added_m$0():-1, org.jboss.aop.proxy$java.util.HashMap
| put():-1, org.jboss.aop.proxy$java.util.HashMap
| <init>():20, TestRunner
| main():46, TestRunner
|
Note that if you turn on debug logging then you'll get a different infinite
loop involving toString().
There is a workaround for this problem. Add an extra field, say hashcode, that
is re-evaluated whenever the appropriate fields change (id in this case), and
use that field in the hashCode() method. Then change the jboss-aop.xml file to
only add an interceptor on the id field, allowing the hashcode to be returned
safely.
| <prepare expr="field(* $instanceof{IdObject}->id)" />
|
However, this workaround isn't acceptable in my case. I don't have complete
control over the objects that get put into the cache, and having to go through
these sorts of hoops is a bit over the top regardless. Note also that the cache
is running in a standalone application.
Has anyone else seen this problem? I'm a little stunned that it hasn't come up
before. Hopefully you guys will be able to fix this. It doesn't look trivial!
Tim.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3854541#3854541
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3854541
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
