June 2012 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] (JBCACHE-1609) LegacyRegionManagerImpl#inactivateRegion locks the parent's entire subtree

by Dennis Reed (Created) (JIRA)

LegacyRegionManagerImpl#inactivateRegion locks the parent's entire subtree -------------------------------------------------------------------------- Key: JBCACHE-1609 URL: https://issues.jboss.org/browse/JBCACHE-1609 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.2.8.GA Reporter: Dennis Reed Assignee: Dennis Reed LegacyRegionManagerImpl#inactivateRegion calls lockManager.lockAll on the parent node, so instead of just locking the parent while the region is inactivated, it locks the parent's entire subtree (the entire cache if the region is a child of the root). In combination with JBCACHE-1608, this causes inactivateRegion to lock the parent's entire subtree and never unlock it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
1
0 / 0

[JBoss JIRA] (JBCACHE-1607) LegacyRegionManagerImpl releases locks from other threads

by Dennis Reed (Created) (JIRA)

LegacyRegionManagerImpl releases locks from other threads --------------------------------------------------------- Key: JBCACHE-1607 URL: https://issues.jboss.org/browse/JBCACHE-1607 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.2.8.GA Reporter: Dennis Reed Assignee: Dennis Reed LegacyRegionManagerImpl calls lockManager.unlockAll(NodeSPI) instead of lockManager.unlockAll(NodeSPI, Owner owner). This will cause it to remove any locks currently held by other threads. Due to JBCACHE- lockManager.unlockAll(NodeSPI) is broken, so the effects are limited to the specific node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

3
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1604) NullPointerException in ResourceDMBean.invoke()

by Takayoshi Kimura (JIRA)

NullPointerException in ResourceDMBean.invoke() ----------------------------------------------- Key: JBCACHE-1604 URL: https://issues.jboss.org/browse/JBCACHE-1604 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: 3.2.7.GA Reporter: Takayoshi Kimura Assignee: Manik Surtani Priority: Minor ResourceDMBean.invoke(String name, Object[] args, String[] sig) throws NullPointerException when sig == null. JMX spec doesn't guarantee it's non-null, so we should check it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
3
0 / 0

[JBoss JIRA] (JBCACHE-1613) Lock TimeoutException when using a JTS transaction manager under load

by Dennis Reed (JIRA)

Dennis Reed created JBCACHE-1613: ------------------------------------ Summary: Lock TimeoutException when using a JTS transaction manager under load Key: JBCACHE-1613 URL: https://issues.jboss.org/browse/JBCACHE-1613 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Transactions Affects Versions: 3.2.8.GA Reporter: Dennis Reed Assignee: Dennis Reed After switching to JTS for transactions, "random" lock timeouts occur: org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn [/foo] after [15000] milliseconds for requestor [GlobalTransaction:<10.1.2.3:12345>:5]! Lock held by [null] at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:157) The actual cause is only logged at TRACE level: TRACE [org.jboss.cache.lock.MVCCLockManager] (RequestProcessor-97) Attempting to unlock /foo TRACE [org.jboss.cache.lock.MVCCLockManager] (RequestProcessor-97) Caught exception and ignoring. java.lang.IllegalMonitorStateException: org.jboss.cache.util.concurrent.locks.OwnableReentrantLock@4d93ddfa[State = 1, empty queue][Locked by GlobalTransaction:<10.1.2.3:12345>:4] at org.jboss.cache.util.concurrent.locks.OwnableReentrantLock.tryRelease(OwnableReentrantLock.java:139) at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1239) at org.jboss.cache.util.concurrent.locks.OwnableReentrantLock.unlock(OwnableReentrantLock.java:105) at org.jboss.cache.util.concurrent.locks.PerElementLockContainer.releaseLock(PerElementLockContainer.java:112) at org.jboss.cache.lock.MVCCLockManager.unlock(MVCCLockManager.java:147) at org.jboss.cache.interceptors.MVCCLockingInterceptor.cleanupLocks(MVCCLockingInterceptor.java:375) at org.jboss.cache.interceptors.MVCCLockingInterceptor.transactionalCleanup(MVCCLockingInterceptor.java:400) at org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePrepareCommand(MVCCLockingInterceptor.java:332) ... The root cause is that JTS commits transactions in a different thread than the one calling commit. Under load, it even uses different threads for each call during the same transaction commit (beforeCompletion/afterCompletion). JBoss Cache stores some data in ThreadLocals, and when different threads call beforeCompletion and afterCompletion for the same transaction, it causes it to mix the data between the transactions causing data corruption. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
8
0 / 0

[JBoss JIRA] (JBCACHE-1615) Improve performance of testsuite DummyInMemoryCacheLoader#remove

by Dennis Reed (JIRA)

Dennis Reed created JBCACHE-1615: ------------------------------------ Summary: Improve performance of testsuite DummyInMemoryCacheLoader#remove Key: JBCACHE-1615 URL: https://issues.jboss.org/browse/JBCACHE-1615 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.2.8.GA Reporter: Dennis Reed Assignee: Dennis Reed org.jboss.cache.loader.testloaders.DummyInMemoryCacheLoader#remove calls recursivelyRemoveChildren. The runtime of the recursive algorithm used by recursivelyRemoveChildren increases at least polynomially with the size of the cache. A simple change to remove the recursion can reduce the runtime to linear with the size of the cache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
2
0 / 0

[JBoss JIRA] (JBCACHE-1614) CacheLoader NonManagedConnectionFactory will not work with JTS transaction manager

by Dennis Reed (JIRA)

Dennis Reed created JBCACHE-1614: ------------------------------------ Summary: CacheLoader NonManagedConnectionFactory will not work with JTS transaction manager Key: JBCACHE-1614 URL: https://issues.jboss.org/browse/JBCACHE-1614 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.2.8.GA Reporter: Dennis Reed Assignee: Dennis Reed org.jboss.cache.loader.NonManagedConnectionFactory uses a ThreadLocal to pass data between prepare() and commit(). The JTS transaction manager can call prepare and commit from different threads when under load. This would cause the NonManagedConnectionFactory to mix up database connections between transactions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues June 2012