4:54 p.m.
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#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...