[jboss-user] [JBoss Cache Users] - NullPointerException in replication (GlobalTransaction lost)

[chtimi2]

I have a strange problem when i try to have both replication and transactions. Each works fine individually, for transactions i use a JTA impl (Atomikos).
It seems to happen when JBC tries to replicate a change, but not any change: there are changes that are replicated correctly, within a transaction.
I can't post the OK and KO cases because that would be too much code, i'm looking for hints here and will post more if requested.
Hopefully this exception will recall someone something.

Looking at the JBC source, the problem that:
TxInterceptor.visitPrepareCommand ( InvocationContext ctx , PrepareCommand command)
  | GlobalTransaction gtx = ctx.getGlobalTransaction; //THIS IS NULL!!!!
  | 
I've made sure the transaction context has been initiated (with Spring's TransactionSynchronizationManager.isActualTransactionActive) but this seems to be saying that it has been lost along the way.

The stack:
________FF__________ReplicatedComponentGlue/addRemoteInvocation/0/isActualTransactionActive: true
  | [org.jboss.cache.interceptors.TxInterceptor][RMI TCP Connection(3)-127.0.0.1] - Caught exception, will now set transaction to roll back
  | java.lang.NullPointerException
  | 	at org.jboss.cache.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:132)
  | 	at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)
  | 	at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
  | 	at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
  | 	at org.jboss.cache.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:140)
  | 	at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)
  | 	at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
  | 	at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
  | 	at org.jboss.cache.interceptors.InvocationContextInterceptor.visitPrepareCommand(InvocationContextInterceptor.java:106)
  | 	at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)
  | 	at org.jboss.cache.interceptors.InterceptorChain.invokeRemote(InterceptorChain.java:316)
  | 	at org.jboss.cache.commands.remote.ReplicateCommand.processSingleCommand(ReplicateCommand.java:139)
  | 	at org.jboss.cache.commands.remote.ReplicateCommand.perform(ReplicateCommand.java:115)
  | 	at org.jboss.cache.marshall.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:319)
  | 	at org.jboss.cache.marshall.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:246)
  | 	at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
  | 	at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:545)
  | 	at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:368)
  | 	at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:775)
  | 	at org.jgroups.JChannel.up(JChannel.java:1274)
  | 	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:462)
  | 	at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:144)
  | 	at org.jgroups.protocols.FRAG2.up(FRAG2.java:192)
  | 	at org.jgroups.protocols.FC.up(FC.java:468)
  | 	at org.jgroups.protocols.pbcast.GMS.up(GMS.java:796)
  | 	at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:192)
  | 	at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233)
  | 	at org.jgroups.protocols.UNICAST.up(UNICAST.java:299)
  | 	at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:873)
  | 	at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:705)
  | 	at org.jgroups.protocols.BARRIER.up(BARRIER.java:136)
  | 	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167)
  | 	at org.jgroups.protocols.FD.up(FD.java:284)
  | 	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:308)
  | 	at org.jgroups.protocols.MERGE2.up(MERGE2.java:144)
  | 	at org.jgroups.protocols.Discovery.up(Discovery.java:263)
  | 	at org.jgroups.protocols.PING.up(PING.java:270)
  | 	at org.jgroups.protocols.TP.passMessageUp(TP.java:1277)
  | 	at org.jgroups.protocols.TP.access$100(TP.java:49)
  | 	at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1830)
  | 	at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1804)
  | 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
  | 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
  | 	at java.lang.Thread.run(Thread.java:619)
What seems strange is that this stack at no point refers to user code. Strange since i used synchronous replication, but maybe the problem comes from that if JBC looks for the transaction context in a ThreadLocal or something like that?

The conf:
<?xml version="1.0" encoding="UTF-8"?>
  | <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.2">
  |     <locking
  |             isolationLevel="READ_COMMITTED"
  |             lockParentForChildInsertRemove="false"
  |             lockAcquisitionTimeout="20000"
  |             nodeLockingScheme="mvcc"
  |             writeSkewCheck="false"
  |             concurrencyLevel="500"/>
  | 	<clustering mode="replication">
  | 	    <jgroupsConfig configFile="udp.xml" />
  |       	<sync />
  |     </clustering>
  | </jbosscache>

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268575#4268575

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268575