8:55 a.m.
[
https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin...
]
Flavia Rainone commented on WFLY-12090:
---------------------------------------
[~tomjenkinson] The explanation is that EJB deployment triggers EJBRemote startup and
triggers RemotingTransactionServiceService startup (those services are lazy). Any of them
will satisfy the recovery in the sense that they will trigger registration of
"ejb" and "txn" as remote service (notice that these remote services
are another type of service, they are not MSC services nor are related with capabilities,
but they will leave Remoting in a satisfactory state so it can be used for communications
with the other server).
Once those EJB components are missing, the RemotingTransacctionServiceService is installed
but, given it is lazy, it does not start. The EJB themselves are not registered with the
transactions, it is just a matter of dependency of MSC services in the server.
The only way to reproduce this bug is having pending XaSubordinateResources in the file
system to be recovered without any app installed. The only way of having that is having a
previous instance of the server gone bad and having the original application undeployed
before the server restarts.
[~ochaloup] I'm not talking about WFTC-62. It appears that this bug does not exist, on
a discussion in our weekly call with [~tomekadamski] I explained to him that the resources
were supposed to not be removed unless there was the recovery afterwards, and he told me
he didn't wait long enough to certify that, so he is going to review that Jira at some
point to see if it was a misunderstanding of the algorithm or if there is really a bug.
I'm talking about the files not being removed because there is no actual recovery
being performed, i.e., those files represent a non-existent resource in the other server.
I'm investigating to see what to do with that.
I'm submitting a patch soon for this, after a discussion with [~bstansberry2] the
conclusion was that we should make RemotingServiceService active, vs keeping it lazy and
adding a mechanism in wildfly-transaction-client that would create a service dependent on
that service every time we needed to recover subordinate resources from the file system.
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)
2621
days inactive
2621
days old
0 comments
1 participants
participants (1)
-
Flavia Rainone (Jira)