Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-17349

[GSS](7.2.z) EJB Recovery unable to authenticate when restarted server is trying to recover ejb xa transactions

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not a Bug
    • Icon: Major Major
    • 7.2.10.GA
    • 7.2.2.GA
    • EJB
    • None
    • Hide

      Add a default authentication context, basically a server level user that allows the servers to authenticate with the other servers involved in the xa transaction, so that it can connect and recover if there is not already an established connection

      $JBOSS_HOME/bin/add-user.sh -a -u txn-user -p txn-user-paSsw0rd1
      /subsystem=elytron/authentication-configuration=ejb-auth:add(authentication-name="txn-user", credential-reference={clear-text="txn-user-paSsw0rd1"})
      /subsystem=elytron/authentication-context=default:add(match-rules=[{authentication-configuration=ejb-auth}])
      /subsystem=elytron:write-attribute(name=default-authentication-context,value=default)
      
      Show
      Add a default authentication context, basically a server level user that allows the servers to authenticate with the other servers involved in the xa transaction, so that it can connect and recover if there is not already an established connection $JBOSS_HOME/bin/add-user.sh -a -u txn-user -p txn-user-paSsw0rd1 /subsystem=elytron/authentication-configuration=ejb-auth:add(authentication-name= "txn-user" , credential-reference={clear-text= "txn-user-paSsw0rd1" }) /subsystem=elytron/authentication-context= default :add(match-rules=[{authentication-configuration=ejb-auth}]) /subsystem=elytron:write-attribute(name= default -authentication-context,value= default )
    • Hide

      unzip -d jboss-eap-7.2/ JBEAP-17349-overlay.zip
      ./bin/standalone.sh
      wait for the xa recovery thread to run.
      This example just contains a file in ejb-xa-recovery that will trigger recovery. It is actually pointing back at localhost, but demonstrates the issue.

      Show
      unzip -d jboss-eap-7.2/ JBEAP-17349 -overlay.zip ./bin/standalone.sh wait for the xa recovery thread to run. This example just contains a file in ejb-xa-recovery that will trigger recovery. It is actually pointing back at localhost, but demonstrates the issue.

      EJB Recovery unable to authenticate when restarted server is trying to recover ejb xa transactions

      If an application is using the programatic configuration to invoke remote EJBs and the EJBs are involved in an XA transaction. If a server crashes leaving xa transactions that need to be recovered, once the server is restarted it is unable to authenticate with the remote server to recovery the transaction. It is possible if the client app invokes the remote server before XA recovery runs, then it would be able to recover (if so, then the xa tx would be recovered at some point). Beyond that it looks like a server level user would need to be added to provide a default-authentication-context that the server can use to authenticate to the other server(s) to be able to recover the transactions.

      public static Context getInitialContext(String host, Integer port, String username, String password) throws NamingException {
         Properties props = new Properties();
         props.put(Context.INITIAL_CONTEXT_FACTORY,  "org.wildfly.naming.client.WildFlyInitialContextFactory");
         props.put(Context.PROVIDER_URL, "remote+http://localhost:8080");
         if(username != null && password != null) {
            props.put(Context.SECURITY_PRINCIPAL, username);
            props.put(Context.SECURITY_CREDENTIALS, password);
          }
         return new InitialContext(props);
      }
      
      21:46:02,577 WARN  [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMFAIL: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
      	at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:96)
      	at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:203)
      	at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:210)
      	at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:206)
      	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
      	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
      	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171)
      	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
      	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
      Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (DIGEST-MD5) are supported
      	at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:444)
      	at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
      	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
      	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
      	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
      	at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
      	at ...asynchronous invocation...(Unknown Source)
      	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:599)
      	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:565)
      	at org.jboss.remoting3.ConnectionInfo$None.getConnection(ConnectionInfo.java:82)
      	at org.jboss.remoting3.ConnectionInfo.getConnection(ConnectionInfo.java:55)
      	at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:499)
      	at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:445)
      	at org.jboss.remoting3.UncloseableEndpoint.getConnectedIdentity(UncloseableEndpoint.java:52)
      	at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentity(RemotingRemoteTransactionPeer.java:89)
      	at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:94)
      	... 8 more
      
      21:46:32,585 WARN  [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.NullPointerException
      	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:738)
      	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:519)
      	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:270)
      	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816)
      	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
      

              tadamski@redhat.com Tomasz Adamski
              rhn-support-bmaxwell Brad Maxwell
              Joerg Baesner
              Votes:
              0 Vote for this issue
              Watchers:
              11 Start watching this issue

                Created:
                Updated:
                Resolved: