[jboss-jira] [JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn

[Flavia Rainone (Jira)]

    [ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13737328#comment-13737328 ] 

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 at 1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139)
> 	at org.wildfly.transaction.client at 1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202)
> 	at org.wildfly.transaction.client at 1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201)
> 	at org.wildfly.transaction.client at 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 at 5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429)
> 	at org.jboss.remoting at 5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46)
> 	at org.jboss.xnio at 3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.jboss.xnio at 3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> 	at org.jboss.xnio.nio at 3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> 	at org.jboss.xnio.nio at 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)