Narayana: interop with IBM Websphere AS ?

[fabiosb]

Our company has a lot of legacy code running in WAS (IBM Websphere Application Server). In the long run we want to replace WAS with JbossAS/Wildfly.

As a first step we would like to run new EJBs in Wildfly and allow legacy code in WAS to invoke them with CORBA IIOP.

With a bit of work we were able to implement such a call, but during invocation transaction context is lost !

Is there any chance that Narayana (embedded in Wildfly) can intercept transaction context passed by WAS?

Thanks,

fabios

[mmusgrov]

WildFly does not support importing foreign transactions yet so it installs an ejb interceptor which throws a transactionPropagationNotSupported exception if it finds that a request includes such a foreign transaction. The transaction manager would also need a patch (we look in a non standard CORBA request slot for the transaction context on incoming IIOP calls).

Whilst these deficiencies are reasonably easy to address the main issue is around recovery. If you just need transaction propagation support for your development and could, in the short term, cope without recovery I could prepare some patches for you (you would need to tell me which version of WildFly you are using). Also do you just need propagation from Websphere to WildFly? Obviously you could never go into production without recovery support so we would need to know when you need this functionality by.

[tomjenkinson]

There are [JBTM-223] Check WL-to-JBossTS interoperability (via JTS). - JBoss Issue Tracker  and [JBTM-2623] Check Glassfish-to-Narayana interoperability (via JTS). - JBoss Issue Tracker  too. Those issues apply to different vendors servers but have a similar aim.

[fabiosb]

In Wildfly I got rid of transactionPropagationNotSupported exception using your patch from quickstart-1/JBTM-223.wildfly.diff .

Patching the transaction manager is much more difficult for me and your help with it would be really appreciated.

For my development I just need transaction propagation from Websphere to Wildfly (version 10.x). At present this is just a proof of concept and I can go on without recovery feature.

[mmusgrov]

The same quickstart contains the transaction manager patch: quickstart-1/JBTM-223.narayana.diff at JBTM-223 · mmusgrov/quickstart-1 · GitHub

Follow the instructions in the readme quickstart-1/interop at JBTM-223 · mmusgrov/quickstart-1 · GitHub to build this transaction manager patch. Then when you build and start WildFly it will use this patched narayana TM via your local maven repo.

[mmusgrov]

So the full instructions (these are also in the quickstart README file) for patching narayana and the two app servers would be (after cd'ing into the quickstart dirctory):

export QS_DIR=$PWD
git clone https://github.com/jbosstm/narayana.git $QS_DIR/tmp/narayana
cd $QS_DIR/tmp/narayana
git checkout 939ba40
git apply $QS_DIR/JBTM-223.narayana.diff
./build.sh clean install -DskipTests
cd $QS_DIR
svn checkout https://svn.java.net/svn/glassfish~svn/trunk/main $QS_DIR/tmp/glassfish
cd $QS_DIR/tmp/glassfish
patch -p0 -i $QS_DIR/GLASSFISH-21532.diff
mvn install -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true -DskipTests
cd $QS_DIR
git clone https://github.com/wildfly/wildfly $QS_DIR/tmp/wildfly
cd $QS_DIR/tmp/wildfly
git checkout 10.0.0.Final
git apply $QS_DIR/JBTM-223.wildfly.diff
./build.sh clean install -DskipTests
export JBOSS_HOME=$QS_DIR/tmp/wildfly/build/target/wildfly-10.0.0.Final

The rest of the README covers starting the app servers, building and deploying the test EJBs and then running the transaction propagation test.

[fabiosb]

I followed instructions to apply patches to narayana and wildfly (not glassfish since it's out of scope for me).

I ran my test against this new wildfly instance ... but transaction context is still not propagated!

Ejb running in wildfly is like this:

@Stateless
@RemoteHome(ISampleEjbHome21.class)
public class SampleEjb21 {
        @TransactionAttribute(TransactionAttributeType.MANDATORY)
        public String echo()  {
            return "echo...echo...echo";
        }
}

and the exception is:

10:44:54,414 TRACE [org.jboss.as.ejb3] (p: default-threadpool; w: Idle) Exception in EJBObject invocation: javax.transaction.TransactionRequiredException: WFLYEJB0062: Transaction is required for invocation org.jboss.invocation.InterceptorContext@3211ac32
    at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:78)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:65)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
    at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
    at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
    at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
    at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
    at org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:329)
    at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
    at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
    at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
    at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
    at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
    at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
    at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
    at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
    at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
    at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
    at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)

Can You recognise I am missing something ?

[tomjenkinson]

mmusgrov - is it possible that WebSphere uses a different slot ID?

Fabio you could debug where we use the slot in:

https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/javaidl/interceptors/interposition/InterpositionClientRequestInterceptorImpl.java

and

narayana/InterpositionServerRequestInterceptorImpl.java at master · jbosstm/narayana · GitHub

You could try to see if the context is lurking in one of the other slots.

Fabio, please provide a reproducer zip with the configs so we can also take a look, in particular I assume you have JTS enabled in WildFly?

[mmusgrov]

Having a reproducer will help. How are you sending the ejb request?

The standard slot ID is zero and Websphere will be using that and so too will the patched WildFly server if you configured it correctly according to the README using the supplied script:

./bin/jboss-cli.sh --connect --file=$QS_DIR/configure-jts-transactions.cli

You can check it is using zero by making sure the wildfly config file (standalone/configuration/standalone-full.xml) contains the line <property name="com.arjuna.ats.jts.transactionServiceId" value="0"/>

Also check that wildfly is using the patched transaction manager (the wildfly patch will have done this). Look in modules/system/layers/base/org/jboss/jts/main/module.xml and make sure it contains <artifact name="org.jboss.narayana.jts:narayana-jts-idlj:5.3.4.Final-SNAPSHOT"/>  in the resources section.

[fabiosb]

I did the checks Michael suggested me, and yes I forgot to run the configure-jts-transactions.cli script. My fault!

Now configuration should be correct. I have attached wildfly standalone config as standalone-full.xml.zip file.

Narayana module used by wildfly is the correct patched version (5.3.4.Final-SNAPSHOT).

Running again my test I got an exception much longer than previous one. I attach it as a error.log.zip file.

As suggested by Tom I also enabled traces for InterpositionClientRequestInterceptorImpl.java class and attach it as interceptor.trace.zip file

Talking about calling ejb, this is what I run in websphere:

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void testRemoteEjb() {
  Hashtable jndiProperties = new Hashtable();
  jndiProperties.put("java.naming.factory.initial", "com.ibm.websphere.naming.WsnInitialContextFactory");
  jndiProperties.put("java.naming.provider.url", "corbaloc::wildfly10:3528");
  Context context = new InitialContext(jndiProperties);
  String jndi = "ejbtest/SampleEjb21";
  Object obj = context.lookup(jndi);
  ISampleEjbHome21 home = (ISampleEjbHome21) obj;
  ISampleEjb21 sample = home.create();
  String echoResp = sample.echo();
  ...
}

[mmusgrov]

The version of narayana that this patch refers to contained a bug. I will recreate the patch on a later revision of narayana and then update the quickstart. I will update this thread when I have done that.

[fabiosb]

Very good. I'll stay tuned.

Thanks a lot

[mmusgrov]

I updated the patch to include the missing fix ([JBTM-2803] compareHierarchies traceln's wrong elements - JBoss Issue Tracker ).

You will need to reapply the patch quickstart-1/JBTM-223.narayana.diff at JBTM-223 · mmusgrov/quickstart-1 · GitHub

[fabiosb]

Re-applied patch and built narayana+wildfly.

Executing my test I'm back with previous exception which states there is no transaction:

11:24:54,122 TRACE [org.jboss.as.ejb3] (p: default-threadpool; w: Idle) Exception in EJBObject invocation: javax.transaction.TransactionRequiredException: WFLYEJB0062: Transaction is required for invocation org.jboss.invocation.InterceptorContext@7d9b7e2a
    at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:78)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:65)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
    at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
    at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
    at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
    at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
    at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
    at org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:329)
    at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
    at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
    at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
    at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
    at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
    at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
    at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
    at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
    at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
    at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
    at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)

Is there a way to dump the content of request slots ?

[mmusgrov]

Can you zip and attach your example. Also does it run with the liberty profile.