September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-760) TreeCacheListener in PojoCache gets nodeModify events for invalid objects

by Nitzan Niv (JIRA)

TreeCacheListener in PojoCache gets nodeModify events for invalid objects -------------------------------------------------------------------------- Key: JBCACHE-760 URL: http://jira.jboss.com/jira/browse/JBCACHE-760 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Affects Versions: 1.4.0.SP1 Reporter: Nitzan Niv Assigned To: Manik Surtani In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object. java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance. at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122) at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92) at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722) at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416) at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268) at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832) at org.jboss.cache.TreeCache._put(TreeCache.java:4425) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321) at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345) at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157) at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520) at org.jboss.cache.TreeCache.put(TreeCache.java:3678) at org.jboss.cache.TreeCache.put(TreeCache.java:3349) at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133) at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273) at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115) at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213) at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731) at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462) at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423) To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is: public void testNodeCreatedAndModifiedMapEvent() throws Exception { EventLog el = new EventLog(cache); cache.addTreeCacheListener(el); Map data = new HashMap(); data.put("key", "value"); cache.putObject("/hello/world", data); ... } and the relevant listener code: public void nodeModify(Fqn fqn, boolean pre, boolean isLocal) { events.add("modify "+ (pre? "about to modify " : "Modified ") + (isLocal? "local " : "remote ") + fqn); if(this.cache != null && !pre) { try { cache.getObject(fqn); } catch (Exception e) { events.add(e); e.printStackTrace(System.err); } } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

3
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-765) implementation of equals() in collections is incorrect

by Nitzan Niv (JIRA)

implementation of equals() in collections is incorrect ------------------------------------------------------ Key: JBCACHE-765 URL: http://jira.jboss.com/jira/browse/JBCACHE-765 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Reporter: Nitzan Niv Assigned To: Ben Wang The implementation of equals() is in PojoCache collections (List, Map) is incorrect (inconsistent with the List and Map interfaces behavior): In Map, equals() returns true for two maps that have the same keys but different mapping (e.g., map1 = ["ID", "1"], map2 = "ID", "2"]). In List, equals() returns true for two lists that have the same elements but in a different order (e.g., list1 = [1][2], list2 = [2][1]). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-695) PojoCache transaction rollback has limitation under certain transaction context

by Ben Wang (JIRA)

PojoCache transaction rollback has limitation under certain transaction context ------------------------------------------------------------------------------- Key: JBCACHE-695 URL: http://jira.jboss.com/jira/browse/JBCACHE-695 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Priority: Minor Fix For: POJOCache Currently PojoCache supports transaction rollback. For instance, cache.attach(id, pojo); is transactional even if there is no user transaction. However, with user transaction, tx.begin(); cache.attach(id, pojo); pojo.setAge(20); tx.rollback(); the replication is rollbacked but the in-memory copy is not, e.g., pojo.getAge() == 20. There is a workaround if you are using transaction by yourself: // Just make sure this one succeeds first. tx.begin(); cache.attach(id, pojo); tx.commit(); // All subsquent field update will be transactional then. tx.begin(); pojo.setAge(20); tx.rollback(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-757) Problem updating cyclic reference

by J?rn Eyrich (JIRA)

Problem updating cyclic reference --------------------------------- Key: JBCACHE-757 URL: http://jira.jboss.com/jira/browse/JBCACHE-757 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Affects Versions: 1.4.0.SP1 Reporter: J?rn Eyrich Assigned To: Manik Surtani import org.jboss.cache.aop.PojoCache; import org.jboss.cache.aop.annotation.PojoCacheable; @PojoCacheable public class Main { public Main reference; public static void main(String[] args) throws Exception { PojoCache cache = new PojoCache(); cache.startService(); Main main = new Main(); Main main2 = new Main(); main.reference = main2; main2.reference = main; cache.putObject("/main",main); main2.reference = main; // <-- System.out.println("Done..."); } } results in: Exception in thread "main" java.lang.RuntimeException: PojoCache.putObject(): fqn: /main/reference/reference at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:478) at org.jboss.cache.aop.CacheInterceptor.invoke(CacheInterceptor.java:115) at org.jboss.aop.joinpoint.FieldWriteInvocation.invokeNext(FieldWriteInvocation.java:51) at Main.reference_w_$aop(Main.java) at Main.main(Main.java:21) Caused by: java.lang.IllegalStateException: AOPInstance.incrementRefCount(): source fqn: /main/reference/reference is already present. at org.jboss.cache.aop.AOPInstance.incrementRefCount(AOPInstance.java:92) at org.jboss.cache.aop.InternalDelegate.incrementRefCount(InternalDelegate.java:98) at org.jboss.cache.aop.ObjectGraphHandler.incrementRefCount(ObjectGraphHandler.java:212) at org.jboss.cache.aop.ObjectGraphHandler.setupRefCounting(ObjectGraphHandler.java:192) at org.jboss.cache.aop.ObjectGraphHandler.objectGraphPut(ObjectGraphHandler.java:88) at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:201) at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731) at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462) ... 4 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

2
5
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-589) PojoCache pojo level locking semantics

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-589?page=all ] Ben Wang resolved JBCACHE-589. ------------------------------ Resolution: Done This is done via TxLockInterceptor. > PojoCache pojo level locking semantics > -------------------------------------- > > Key: JBCACHE-589 > URL: http://jira.jboss.com/jira/browse/JBCACHE-589 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0 > > > When using pessimistic locking, we need to provide a pojo level locking semantics. Current one uses only node level and there is big problem when the node is not yet exist since we can't lock it that way. Idea maybe to provide an extra lock interceptor that tracks the pojo-level locking. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-157) Use privileged action in CacheInterceptor

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-157?page=all ] Ben Wang updated JBCACHE-157: ----------------------------- Fix Version/s: 2.1.0 (was: 2.0.0) This should be implemented along the overall context of JBoss Cache not just PojoCache. > Use privileged action in CacheInterceptor > ----------------------------------------- > > Key: JBCACHE-157 > URL: http://jira.jboss.com/jira/browse/JBCACHE-157 > Project: JBoss Cache > Issue Type: Patch > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: 1.2.2 > Environment: Standalone JDK 1.5 application with custom security policy > Reporter: twundke > Assigned To: Ben Wang > Fix For: 2.1.0 > > Attachments: CacheInterceptor.patch > > > When using the AOP version of JBoss Cache in a security-managed environment, various classes require certain permissions (such as org.jboss.cache.aop.CachedType requiring java.lang.RuntimePermission "accessDeclaredMembers"). This also means that any class accessing a cached object must be granted these permissions. > There are a number of problems with this. The first is that it breaks the transparency of using AOP-ed objects with the cache, as users of these objects must be granted additional permissions. The second problem is the nature of the permissions that must be granted. They are powerful permissions that allow runtime reflection, and in my particular case cannot be granted to the code using cached objects. > The solution is to wrap the CacheInterceptor.invoke() method in a call to AccessController.doPrivileged() when a security manager is present. This allows the necessary permissions to be granted to the cache, without affecting the permissions of the calling code. > The attached patch does just that. However, I don't know if this will have an effect on using the cache within a managed environment. I suspect not, but have no way of testing this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-30) Multiple MBean Configuration Error

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-30?page=all ] Ben Wang resolved JBCACHE-30. ----------------------------- Resolution: Out of Date This will be out of date with our 2.0 release. > Multiple MBean Configuration Error > ---------------------------------- > > Key: JBCACHE-30 > URL: http://jira.jboss.com/jira/browse/JBCACHE-30 > Project: JBoss Cache > Issue Type: Bug > Affects Versions: 1.2 > Reporter: SourceForge User > Assigned To: Ben Wang > Fix For: 2.0.0 > > > SourceForge Submitter: jiwils . > Some if not all of the JBossCache configuration XML > files contain the following commented MBean definition: >  >  >  >  >  > By uncommenting this MBean definition, I thought I > would get a GUI with which I could inspect the cache, > but instead I got a "multiple MBean" exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-450) Create a pure pojo-based eviction policy

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-450?page=all ] Ben Wang updated JBCACHE-450: ----------------------------- Fix Version/s: 2.0.0 (was: PojoCache) > Create a pure pojo-based eviction policy > ---------------------------------------- > > Key: JBCACHE-450 > URL: http://jira.jboss.com/jira/browse/JBCACHE-450 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > The eviction policy module has been refactored in 1.3. We will need to refactor the pojo-based evitction policy as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-584) Investigate use of lazy mapping for PojoCache

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-584?page=all ] Ben Wang updated JBCACHE-584: ----------------------------- Fix Version/s: PojoCache 2.1.0 (was: PojoCache 2.2.0) > Investigate use of lazy mapping for PojoCache > --------------------------------------------- > > Key: JBCACHE-584 > URL: http://jira.jboss.com/jira/browse/JBCACHE-584 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: PojoCache 2.1.0 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Recent perf test on PojoCache shows bottleneck is on the initial mapping of putObject causing numerous trips to the local cache store. To optimize it further, either the TreeCache local mode need to be enhanced. Or one solution to this is the use of lazy mapping of the pojo. For example, when putObject is called, pojo is not mapped. Instead, it is stored under a "Serialized" state (can use JBossSerialization if pojo is not even Seriailizable) first. Then when the field is modified (detected from the CacheInterceptor), we will then map it lazily to the PojoCache store. > The performance gain can be had, if 1) initial saving of mapping, 2) field update is only selected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-685) Integration using the new Cache2.0 API and SPI

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-685?page=all ] Ben Wang resolved JBCACHE-685. ------------------------------ Resolution: Done > Integration using the new Cache2.0 API and SPI > ---------------------------------------------- > > Key: JBCACHE-685 > URL: http://jira.jboss.com/jira/browse/JBCACHE-685 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0 > > > Currently, PojoCache 2.0 development is still using the old TreeCache API. It would be nice to migrate to 2.0 API when it is completed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2006