[JBoss Messaging] - Re: Client Connection Delegate has Null state
by mmarcuci
I've updated the aop jar to the recommended version and now get this error
Caused by: java.lang.AbstractMethodError: getLoaderRepository
at org.jboss.aop.AspectManager.instance(AspectManager.java:340)
at org.jboss.aop.AspectManager.instance(AspectManager.java:255)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.(ClientConnectionFactoryDelegate.java)
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
at java.lang.reflect.Field.getLong(Field.java:528)
at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614)
at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425)
at java.io.ObjectStreamClass.(ObjectStreamClass.java:413)
at java.io.ObjectStreamClass.lookup0(ObjectStreamClass.java:310)
at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java)
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at java.rmi.MarshalledObject.get(MarshalledObject.java:142)
at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
It looks as thought the implementation of AOPScopedClassLoaderHelper that is used within AspectManager does not implement this method. The only implementation in my classpath is JBossScopedClassLoaderHelper, and the class signature doesn't have this method. The class is defined in jboss-aspect-library-jdk50.jar, version jboss-aspect-library-1.5.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216800#4216800
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216800
17 years, 1 month
[JBoss Cache: Core Edition] - Re: is it possible for MVCCInvocationContext to have null mv
by dukehoops
To follow up further. Below is a test i wrote trying to capture above failure. When I run it I observe the following:
- if no debugger is used, test passes
- if I step through with a debugger when EvictCommand.perform calls ctx.lookUpNode(fqn) the underlying MVCCInvocationContext sometimes has a non-null mvccTCtx and sometimes mvccTCtx is null?! It seems to depend on where I break and for how long - though pattern is unclear.
When mvccTCtx is null, then Node in question *is* found in lookedUpNodes and eviction proceeds.
When mvccTCtx is NOT null, it does not contain the node in question -> ctx.lookUpNode returns null (lookedUpNodes isn't consulted if mvccTCtx is null) and eviction does not proceed (command.perform returns true immediately)
Questions:
1. From my understanding ctx.mvccTCtx should NOT be null when used accessed from EvictCommand.perform in the above test. Do you agree? If not, why (how is it that mvccTCtx can be null in this case)?
2. Since it seems I can affect the outcome of the test merely by attaching a debugger and breaking throughput, I am guessing either multiple threads or timestamping is involved. Given that the entire duration of the test didn't exceed 40-50 seconds (including my think time) when varying results were obtained, this does not seem to be related to underlying JTA tx timing out. Any idea where to look for debugger breaks can affect?
thanks
-nikita
package org.jboss.cache.api;
|
| import org.jboss.cache.config.Configuration;
| import org.jboss.cache.config.Configuration.NodeLockingScheme;
| import org.jboss.cache.factories.UnitTestConfigurationFactory;
| import org.testng.annotations.Test;
|
| import javax.transaction.TransactionManager;
|
| import org.jboss.cache.*;
| import org.jboss.cache.lock.IsolationLevel;
|
| /**
| * Tests that a node that was putFromExternalRead and then removed in TX1 does NOT
| * get returned in subsequent TX2.
| *
| * @author nikita_tovstoles(a)mba.berkeley.edu
| * @since 3.0.3.GA
| */
| @Test(groups = {"functional", "pessimistic"}, sequential = true, testName = "api.RemovedNodeResurrectionInSubsequentTxTest")
| public class RemovedNodeResurrectionInSubsequentTxTest extends AbstractSingleCacheTest {
|
| private static final Fqn A_B = Fqn.fromString("/a/b");
| private static final Fqn A = Fqn.fromString("/a");
| private static final Fqn A_C = Fqn.fromString("/a/c");
| private static final String KEY = "key";
| private static final String VALUE = "value";
| private static final String K2 = "k2";
| private static final String V2 = "v2";
| protected NodeSPI root;
| protected TransactionManager txManager;
|
| public CacheSPI createCache() {
| CacheSPI myCache = (CacheSPI<Object, Object>) new UnitTestCacheFactory<Object, Object>().createCache(UnitTestConfigurationFactory.createConfiguration(Configuration.CacheMode.LOCAL, true), false, getClass());
| myCache.getConfiguration().setCacheMode(Configuration.CacheMode.LOCAL);
| myCache.getConfiguration().setCacheLoaderConfig(null);
| myCache.getConfiguration().setNodeLockingScheme(NodeLockingScheme.MVCC);
| configure(myCache.getConfiguration());
| myCache.start();
| root = myCache.getRoot();
| txManager = myCache.getTransactionManager();
|
| return myCache;
| }
|
| protected void configure(Configuration c) {
| c.setIsolationLevel(IsolationLevel.REPEATABLE_READ);
| }
|
| public void testPferAndEvictInSameTx() throws Exception {
|
| Object val = null;
|
| cache.getRoot().addChild(A);
|
| txManager.begin();
|
| //put in cache
| cache.putForExternalRead(A, KEY, VALUE);
|
| //evict from cache
| cache.evict(A); //sometimes MVCCInvocationContext has ref to mvccTCtx, sometimes NOT
|
| //verify eviction
| val = cache.get(A, KEY);
| assert val == null : "get() after evict() returned " + val;
|
| txManager.commit();
|
| }
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216794#4216794
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216794
17 years, 1 month