[JBoss JIRA] Created: (JBCACHE-710) CacheLoader passivation/activation produces recursive exception when loader.remove fails
by Ben Wang (JIRA)
CacheLoader passivation/activation produces recursive exception when loader.remove fails
----------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Critical
Fix For: 2.0.0
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader (I am using FileCacheLoader), e.g., DataNotRemovedException. That way, ActivationInterceptor can catch it here and skip event notification (since it won't be valid anyway).
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBCACHE-833) Redundant lock in cache loader
by Ben Wang (JIRA)
Redundant lock in cache loader
------------------------------
Key: JBCACHE-833
URL: http://jira.jboss.com/jira/browse/JBCACHE-833
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0.SP1, 1.4.0.GA
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Minor
Fix For: 2.0.0.GA
Currently in CacheLoader, it calls "lock" from loadIfNeeded method. The "lock" method in turns invokes
TreeCache.java
public void _lock(Fqn fqn, DataNode.LockType lock_type, boolean recursive)
throws TimeoutException, LockingException
{
log.warn("method _lock() should not be invoked on TreeCache");
}
I think the LockInterceptor should take care of the locking properly. So this call should be deprecated.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBCACHE-995) Test failure - org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
by Rajesh Rajasekaran (JIRA)
Test failure - org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
-------------------------------------------------------------------
Key: JBCACHE-995
URL: http://jira.jboss.com/jira/browse/JBCACHE-995
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Rajesh Rajasekaran
Assigned To: Manik Surtani
Fix For: 2.0.0.BETA1
org.jboss.cache.multiplexer.BuddyGroupAssignmentTest fails on the release distribution.
To reproduce:
run ./build.sh dist.
Unzip JBossCache-all-2.0.0.BETA1.zip
Run ant one.test -Dtest=org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
<testcase classname="org.jboss.cache.multiplexer.BuddyGroupAssignmentTest" name="testRemovalFromCluster2Buddies" time="24.523">
<failure message="10.16.7.254:60612 should be a buddy to 10.16.7.254:60606" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: 10.16.7.254:60612 should be a buddy to 10.16.7.254:60606
at org.jboss.cache.buddyreplication.BuddyReplicationTestsBase.assertIsBuddy(BuddyReplicationTestsBase.java:285)
at org.jboss.cache.buddyreplication.BuddyGroupAssignmentTest.testRemovalFromCluster2Buddies(BuddyGroupAssignmentTest.java:131)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
</failure>
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBCACHE-740) Optimistic Locking Scheme: Occasional IllegalStateExceptions on commit
by Carsten Krebs (JIRA)
Optimistic Locking Scheme: Occasional IllegalStateExceptions on commit
----------------------------------------------------------------------
Key: JBCACHE-740
URL: http://jira.jboss.com/jira/browse/JBCACHE-740
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.0
Environment: Linux 2.6.15-26-686 #1 SMP PREEMPT Thu Aug 3 03:13:28 UTC 2006 i686 GNU/Linux
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
JOTM 2.0.10
JUnit 3.8.1
Reporter: Carsten Krebs
Assigned To: Manik Surtani
Fix For: 2.0.0
The unit test below reproduces "occasional" IllegalStateExceptions (s.b.) on commiting a transaction. This test tries to modify the same node at the same time by different threads in different transactions using the optimistic locking scheme.
java.lang.IllegalStateException: there is already a writer holding the lock: GlobalTransaction:<null>:43
at org.jboss.cache.lock.LockMap.setWriterIfNotNull(LockMap.java:96)
at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:204)
at org.jboss.cache.Node.acquireWriteLock(Node.java:431)
at org.jboss.cache.Node.acquire(Node.java:386)
at org.jboss.cache.interceptors.OptimisticLockingInterceptor.lockNodes(OptimisticLockingInterceptor.java:149)
at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:76)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:804)
at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1069)
at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)
at org.objectweb.jotm.SubCoordinator.doBeforeCompletion(SubCoordinator.java:1487)
at org.objectweb.jotm.SubCoordinator.commit_one_phase(SubCoordinator.java:416)
at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:239)
at OptimisticLockingTest$Worker.run(OptimisticLockingTest.java:135)
The Cache Config:
-------------------------
<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TreeCache">
<attribute name="NodeLockingScheme">OPTIMISTIC</attribute>
<attribute name="CacheMode">LOCAL</attribute>
</mbean>
</server>
The Unit Test:
-------------------
import javax.transaction.Transaction;
import javax.transaction.TransactionManager;
import junit.framework.TestCase;
import org.jboss.cache.CacheException;
import org.jboss.cache.PropertyConfigurator;
import org.jboss.cache.TransactionManagerLookup;
import org.jboss.cache.TreeCache;
import org.objectweb.jotm.Current;
import EDU.oswego.cs.dl.util.concurrent.CyclicBarrier;
/**
* OptimisticLockingTest
*/
public class OptimisticLockingTest extends TestCase {
private static final String NODE_PATH = "/path/node";
private static final String KEY = "key";
private static final Current jotm = new Current();
private TreeCache cache;
protected void setUp() throws Exception {
super.setUp();
cache = new TreeCache();
final PropertyConfigurator config = new PropertyConfigurator();
cache.setTransactionManagerLookup(new TransactionManagerLookup() {
public TransactionManager getTransactionManager() throws Exception {
return Current.getTransactionManager();
}
});
config.configure(cache, this.getClass().getResourceAsStream(
"/cache-config.xml"));
cache.startService();
}
public void testSimultanWrite() throws Exception {
for (int i = 2; i < 20; i++) {
System.out.println(">> testing simultaneous writes with " + i
+ " threads...");
testSimultanWrite(i);
}
}
public void testSimultanWrite(final int _numThreads) throws Exception {
final CyclicBarrier barrier = new CyclicBarrier(_numThreads);
Worker[] workers = new Worker[_numThreads];
for (int i = 0; i < workers.length; i++) {
workers[i] = new Worker();
workers[i].barrier = barrier;
workers[i].value = "worker" + i;
if (i == 0) {
workers[i].isMaster = true;
}
workers[i].start();
}
for (int i = 0; i < workers.length; i++) {
workers[i].join();
}
assertNull(workers[0].exception);
for (int i = 0; i < workers.length; i++) {
assertNull("rollback failed", workers[i].rollbackException);
}
for (int i = 1; i < workers.length; i++) {
assertNotNull("missing exception", workers[i].exception);
assertTrue("exception is not of type CacheException",
workers[i].exception.getCause() instanceof CacheException);
}
assertEquals("worker0", cache.get(NODE_PATH, KEY));
cache.getTransactionManager().begin();
cache.remove(NODE_PATH);
cache.getTransactionManager().commit();
}
private class Worker extends Thread {
private CyclicBarrier barrier;
private Exception exception;
private Exception rollbackException;
private String value;
private boolean isMaster;
/**
* @see java.lang.Thread#run()
*/
public void run() {
final TransactionManager txManager = cache.getTransactionManager();
Transaction tx = null;
try {
// wait for all threads started
barrier.barrier();
if (isMaster) {
txManager.begin();
cache.put(NODE_PATH, KEY, value);
// lets the other threads start writing
barrier.barrier();
// wait for other threads to their modification
barrier.barrier();
// commit first
tx = txManager.getTransaction();
tx.commit();
// lets the other threads commit
barrier.barrier();
} else {
// wait for master to start transaction
barrier.barrier();
txManager.begin();
cache.put(NODE_PATH, KEY, value);
// signal modification
barrier.barrier();
// wait for master to commit transaction
barrier.barrier();
tx = txManager.getTransaction();
tx.commit();
}
} catch (Exception e) {
exception = e;
try {
tx.rollback();
} catch (Exception e1) {
rollbackException = e1;
}
}
}
}
}
--
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
18 years, 9 months