April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBCACHE-518) Investigate use a new replication schema for PojoCache

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-518?page=all ] Jason T. Greene updated JBCACHE-518: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Investigate use a new replication schema for PojoCache > ------------------------------------------------------ > > Key: JBCACHE-518 > URL: http://jira.jboss.com/jira/browse/JBCACHE-518 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache 2.2.0 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > We should look into a new replication schema for PojoCache putObject and removeObject operation. Idea is during replication, instead of breaking it down and do lots of puts, we replicate the original objects and map it into PojoCache on the other side. This has potential of saving the binary size but has pontential to be more cpu intensive. > The other issue is what to do with automicity during putObject and removeObject? -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-467) ejb3 annotation integration

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-467?page=all ] Jason T. Greene updated JBCACHE-467: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > ejb3 annotation integration > --------------------------- > > Key: JBCACHE-467 > URL: http://jira.jboss.com/jira/browse/JBCACHE-467 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache 2.1.0 > > -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-687) PojoCache to use aop 2.0 to bind interceptor dynamically

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-687?page=all ] Jason T. Greene updated JBCACHE-687: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > PojoCache to use aop 2.0 to bind interceptor dynamically > -------------------------------------------------------- > > Key: JBCACHE-687 > URL: http://jira.jboss.com/jira/browse/JBCACHE-687 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: 2.1.0.GA > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Currently in 2.0, I am introducing new field level interceptos such as SubjectInterceptor to emit the field events. However, make "introduction" to a POJO with a Subject interface also has the side effect of the interceptor will bind to that method jointpoint as well. This is not desirable. > Workaround is to check for MehtodInvocation is each field level interceptor or in AOP2.0, we can bind specifically to the Pointcut programmtically as discussed in the forum post. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-466) Create api-less annotation for PojoCache

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-466?page=all ] Jason T. Greene updated JBCACHE-466: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Create api-less annotation for PojoCache > ---------------------------------------- > > Key: JBCACHE-466 > URL: http://jira.jboss.com/jira/browse/JBCACHE-466 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache 2.2.0 > > Original Estimate: 4 weeks > Remaining Estimate: 4 weeks > > Use annotation to signifyas per the spec documentation: @attach, @reattach -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-413) Split up build.xml

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-413?page=all ] Jason T. Greene updated JBCACHE-413: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Split up build.xml > ------------------ > > Key: JBCACHE-413 > URL: http://jira.jboss.com/jira/browse/JBCACHE-413 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Priority: Minor > Fix For: 2.0.0.GA > > Original Estimate: 1 day > Remaining Estimate: 1 day > > buidl.xml is getting too big. Maybe we should split them up, e.g., split the pojo cache portion is a starter. We can do it as JbossAs with import directory. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-97) ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-97?page=all ] Jason T. Greene updated JBCACHE-97: ----------------------------------- Assignee: Jason T. Greene (was: Ben Wang) > ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock > ------------------------------------------------------------------------------------------------- > > Key: JBCACHE-97 > URL: http://jira.jboss.com/jira/browse/JBCACHE-97 > Project: JBoss Cache > Issue Type: Bug > Reporter: Bela Ban > Assigned To: Jason T. Greene > Fix For: 2.1.0.GA > > > TxDeadlockUnitTestCase has 2 methods that show the following stack traces: > testMoreThanOneUpgrader: > Upgrader#0: get(/a/b/c) > Upgrader#1: get(/a/b/c) > main: locks: > /a (read owners=[<null>:2, <null>:1]) > /b (read owners=[<null>:2, <null>:1]) > /c (read owners=[<null>:2, <null>:1]) > Upgrader#0: put(/a/b/c) > Upgrader#1: put(/a/b/c) > Upgrader#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:2); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock) > Upgrader#0: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2] > Write lock owner: null > (caller=<null>:1) > org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2] > Write lock owner: null > (caller=<null>:1) > at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155) > at org.jboss.cache.Node.acquireWriteLock(Node.java:448) > at org.jboss.cache.Node.acquire(Node.java:417) > at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199) > at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) > at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998) > at org.jboss.cache.TreeCache.put(TreeCache.java:1657) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyUpgrader._run(TxDeadlockUnitTestCase.java:346) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213) > and > testConcurrentUpgrade(): > MyThread#1: get(/a/b/c) > MyThread#2: get(/a/b/c) > MyThread#2: done, locks: > /a (read owners=[<null>:2]) > /b (read owners=[<null>:2]) > /c (read owners=[<null>:2]) > MyThread#1: done, locks: > /a (read owners=[<null>:2, <null>:1]) > /b (read owners=[<null>:2, <null>:1]) > /c (read owners=[<null>:2, <null>:1]) > MyThread#2: put(/a/b/c) > MyThread#1: put(/a/b/c) > MyThread#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:1); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock) > MyThread#2: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1] > Write lock owner: null > (caller=<null>:2) > org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1] > Write lock owner: null > (caller=<null>:2) > at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155) > at org.jboss.cache.Node.acquireWriteLock(Node.java:448) > at org.jboss.cache.Node.acquire(Node.java:417) > at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199) > at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) > at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998) > at org.jboss.cache.TreeCache.put(TreeCache.java:1657) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyThread._run(TxDeadlockUnitTestCase.java:317) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213) -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-947) Optimization in attach and detach; reduce calls to getPojo()

by Elias Ross (JIRA)

Optimization in attach and detach; reduce calls to getPojo() ------------------------------------------------------------ Key: JBCACHE-947 URL: http://jira.jboss.com/jira/browse/JBCACHE-947 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: PojoCache Affects Versions: PojoCache Reporter: Elias Ross Assigned To: Ben Wang PojoCache.attach() calls getPojo() at least three times. Once in putObjectI() to determine if the existing object is the same as the attaching object (fairly rare condition), then once again in putObjectII() (which might be redundant.) Then, it calls detach() which calls getPojo() -- see below. I believe that simply calling pCache.detach() and returning the old value might be sufficient. Also, detach() likewise locates the object before removal, though the removal method itself returns the original object. This is because notification includes the original object before removal. In some cases, notification may not be required. It may also be better to refactor the notification listener so that every removal doesn't require two calls to "getPojo". I discovered this following the number of calls made in a profiler tool. -- 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

17 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-736) PojoCache passivation failure

by Ben Wang (JIRA)

PojoCache passivation failure ----------------------------- Key: JBCACHE-736 URL: http://jira.jboss.com/jira/browse/JBCACHE-736 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Affects Versions: 1.4.0 Reporter: Ben Wang Assigned To: Ben Wang In release 1.4 of PojoCache, passivation won't work becuase the new AopEvictionInterceptor and that we override the evict method such that we issue recursiveEvict that in turn is doing _remove(). Becuase of this, it bypasses the passivation interceptor. However, the fix is not so obvious. As it also involves the eviction paradigm for POJo as well. In 2.0 instead, I have opted for not to over-ride evict such that we would only support passivation on a node basis (instead of POJO). This way, passivation is transparent to the POJO level. I have a passivation package to test out these cases. -- 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

17 years, 9 months

3
4
0 / 0

[JBoss JIRA] Updated: (JBCACHE-165) Option to exclude fields from "aspectized" in aop

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-165?page=all ] Jason T. Greene updated JBCACHE-165: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Option to exclude fields from "aspectized" in aop > ------------------------------------------------- > > Key: JBCACHE-165 > URL: http://jira.jboss.com/jira/browse/JBCACHE-165 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Priority: Minor > Fix For: 2.1.0.GA > > Original Estimate: 2 days > Remaining Estimate: 2 days > > There may a time when a user wants certain fields in the POJO to be excluded from TreeCacheAop management. Currently, if a field is declared "transient", we have that effect. But still we may want to have a flag for this specific purpose. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1007) Synchronization impls should scrub state in afterCompletion

by Brian Stansberry (JIRA)

Synchronization impls should scrub state in afterCompletion ----------------------------------------------------------- Key: JBCACHE-1007 URL: http://jira.jboss.com/jira/browse/JBCACHE-1007 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Priority: Minor Fix For: 2.0.0.CR1 I've seen cases where transaction manager's hold refs to Synchronization objects for a while after the tx commits. This can give the appearance of memory leaks if the Synchronization holds state and someone is testing for leaks of objects linked to that state. Also, a user reports that JOTM is not releasing refs to Synchronizations, thus leaking anything referred to from the Synchronization (see forum thread.) Solution to this is to have the Synchronization clear its internal state in a finally block in afterCompletion(). Once that method executes, the state is no longer needed. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=104067 for more on this. If possible, it's also good to have the Synchronization impl be a static class, so there is no, for example, TxInterceptor.this ref leading back to the interceptor from TxInterceptor$RemoteSynchronizationHandler. This is a minor issue, since if the TM does what it should and eventually drops the ref to the Synchronization, the issue cleans itself up. But clearing the Synchronization state aggressively helps avoid the appearance of leaks, and also helps unit tests that check for classloader leaks to ignore spurious stuff. -- 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

17 years, 9 months

2
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2007