Agile Is Not Synchronizing Administration Changes to Configuration Made in the Clustered Instance (Doc ID 2506883.1)

Last updated on DECEMBER 08, 2022

Applies to:

Symptoms

Agile is not synchronizing changes to configuration made in one cluster node to another node with the below errors:

<Warning> <RMI> <[STANDBY] ExecuteThread: '16' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1549298251519> <BEA-080004> <An error was generated by the RMI server: weblogic.transaction.internal.CoordinatorImpl.startRollback(Ljavax.transaction.xa.Xid;Ljava.lang.String;[Ljava.lang.String;Lweblogic.security.acl.internal.AuthenticatedUser;[Ljava.lang.String;Ljava.util.Map;Z)
java.lang.AssertionError: Assertion violated.
java.lang.AssertionError: Assertion violated
at weblogic.utils.Debug.assertion(Debug.java:58)
at weblogic.server.channels.ChannelService.findOutboundServerChannelInternal(ChannelService.java:1805)
at weblogic.server.channels.ChannelService.getOutboundServerChannel(ChannelService.java:2211)
at weblogic.protocol.ServerChannelManager.findOutboundServerChannel(ServerChannelManager.java:303)
at weblogic.rjvm.RJVMImpl.getOutboundRequest(RJVMImpl.java:836)
at weblogic.rmi.internal.BasicRemoteRef.getRequest(BasicRemoteRef.java:237)
at weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest(BasicRemoteRef.java:201)
at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:465)
at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:285)
at weblogic.jndi.internal.ServerNamingNode_12130_WLStub.lookup(Unknown Source)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:440)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:426)
at org.glassfish.transaction.CoordinatorFactoryCommon$JNDILookUpAction.run(CoordinatorFactoryCommon.java:252)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)

and also

[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1549471609464> <BEA-040498> <An error occurred while forwarding a message for distributed destination member cluster-jms!JMSServer2@Distributed sync_topic: weblogic.transaction.RollbackException: Timed out tx=BEA1-0052D2A3F72976B09E78 after 180 seconds
weblogic.transaction.RollbackException: Timed out tx=BEA1-0052D2A3F72976B09E78 after 180 seconds
       at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:2003)
       at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:370)
       at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:261)
       at weblogic.jms.backend.BEForwardingConsumer.processMessages(BEForwardingConsumer.java:530)
       at weblogic.jms.backend.BEForwardingConsumer.pushMessages(BEForwardingConsumer.java:322)
       at weblogic.messaging.util.DeliveryList.run(DeliveryList.java:263)
       at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:553)
       at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)
       at weblogic.work.ExecuteThread.run(ExecuteThread.java:263)
Caused By: weblogic.transaction.internal.TimedOutException: Timed out tx=BEA1-0052D2A3F72976B09E78 after 180 seconds
       at weblogic.transaction.internal.ServerTransactionImpl.wakeUp(ServerTransactionImpl.java:1934)
       at weblogic.transaction.internal.ServerTransactionManagerImpl.processTimedOutTransactions(ServerTransactionManagerImpl.java:1727)
       at org.glassfish.transaction.TransactionManagerImplCommon.wakeUp(TransactionManagerImplCommon.java:1216)
       at weblogic.transaction.internal.ServerTransactionManagerImpl.wakeUp(ServerTransactionManagerImpl.java:1639)
       at weblogic.transaction.internal.WLSTimer.timerExpired(WLSTimer.java:20)
       at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:304)
       at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:553)
       at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)

Facts

1. The JMS server have already configured for each managed server. 
2. When manually run 'synchronization' in Cache Health Monitor page, the changes are propagated to web client

Changes

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.