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

Details

    • Bug
    • Resolution: Not a Bug
    • 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.

    Description

      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)

      Attachments

        Issue Links

          is cloned by

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-18310 [GSS](7.4.z) EJB Recovery unable to authenticate when restarted server is trying to recover ejb xa transactions

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          is related to

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-16149 [GSS](7.2.z) JBREM000308: Authentication failed (no mechanisms left) when EJB invocations across servers done with programatic auth

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: