[
https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin...
]
Flavia Rainone commented on WFLY-12090:
---------------------------------------
[~ochaloup] I correct myself. After investigating, I can see that the not cleaning log
files occurs everytime the server restarts, i.e., WFTC-62 is the cause of the problem
here. Hence, differently than I first thought, the behavior I'm observing with the
logs not being deleted has nothing to do with the fact that there is no EJB to perform
recovery on the other side of the server. I'll link WFTC-62 to this Jira as well,
since we have now a simpler reproducer than using OpenShift, and I'll submit a PR.
Unknown service name jboss.ejb and txn
--------------------------------------
Key: WFLY-12090
URL:
https://issues.jboss.org/browse/WFLY-12090
Project: WildFly
Issue Type: Bug
Components: EJB, Transactions
Affects Versions: 17.0.0.Alpha1
Reporter: Flavia Rainone
Assignee: Flavia Rainone
Priority: Major
Fix For: 17.0.0.Beta1
When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have
the following sort of error:
{code}
16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local
XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR:
javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this
operation
at
org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139)
at
org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202)
at
org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201)
at
org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197)
at
org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
at
org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
at
org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171)
at
org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
at
org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb
at
org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429)
at
org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46)
at
org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at
org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at
org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at
org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn
... 6 more
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)