6 Replies Latest reply on Mar 26, 2009 5:27 AM by olivier motelet

    Opening a new JMS session for an already existing transactio

    olivier motelet Newbie

      Hi,

      Is it possible to open a new JMS session for an existing transaction with JBM 1.4?

      I imagine that it is what happens when a connection generated by a ClusteredConnectionFactory manages the failover of a JBM cluster node, does it?

      Let me introduce the context of my question:

      We have a cluster of JBossMessaging instances. For technical limitations of our legacy system, we need to transmit some messages to our cluster via http. In this case, a client sends a message via http, a web application based on each node of our cluster retrieves the messages coming from http, transforms it in jms and send it to JBM. (JBM and the web app are on the same JBOSS instance and both are replicated on each node of our cluster).

      We want to manage transactions in http as we do in jms. In order to enable that feature, when a transaction is done via http, the web app stores all the messages of the transaction in Session. When the transaction finishes (commit), the stored messages are sent in a jms transaction on JBM and the stored messages are removed from the Session.
      The Session content of the web app is replicated in the cluster (sticky Session is used on the loadBalancer). When a node fails, all the messages of the transaction are still available: we’ve done the failover.

      However, this solution is not safe since we cannot ensure (functionally) that the number of messages of the transactions will not overflow the cluster node memory.

      An alternative solution consists in keeping in the content of the replicated http-session a jms- session created for the transaction. Then the messages received in the transaction via http are sent on-the-fly to JBM (in jms). The jms-transaction is committed or rolled-back when one of these operations is received via http. With this solution, the memory problem is delegated to JBM. Nevertheless, it is no more possible to make the failover: the jms-session replicated in the http-session cannot be reused by other threads (and thus cluster nodes) than its creator.

      Since it is not possible to use the replicated jms-session object if the creator node fails, is it possible to open a new JMS session on a living cluster node for the already started transaction?


      Thanks for your help !

      olivier

        • 1. Re: Opening a new JMS session for an already existing transa
          Andy Taylor Master

          If you are using an XASession then you can join an already running tx if you know the Xid, just specify the Join flags:

          XAResource res = xaSession.getXAResource();
          res.start(xid, XAResource.TMJOIN);
          


          • 2. Re: Opening a new JMS session for an already existing transa
            olivier motelet Newbie

            Hello,
            thx for your answer, we finally had time to try a version using XA.

            We tried to share in cluster the XAConnection so that when a node fails the transaction can continue on the other nodes using this shared connection:

            XASession session = mySharedXAConnection.createXASession();
            XAResource resource = session.getXAResource();
            resource.start(mySharedXID, XAResource.TMJOIN);
            


            Nevertheless, we got the following error when doing the
            mySharedXAConnection.createXASession();


            
            18:17:52,375 INFO [STDOUT] java.lang.NullPointerException
            18:17:52,375 INFO [STDOUT] at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:87)
            18:17:52,375 INFO [STDOUT] at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
            18:17:52,375 INFO [STDOUT] at org.jboss.jms.client.delegate.ClientConnectionDelegate$createSessionDelegate_6052335267724906805.invokeNext(ClientConnectionDelegate$createSessionDelegate_6052335267724906805.java)
            18:17:52,375 INFO [STDOUT] at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
            18:17:52,375 INFO [STDOUT] at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
            18:17:52,375 INFO [STDOUT] at org.jboss.jms.client.delegate.ClientConnectionDelegate$createSessionDelegate_6052335267724906805.invokeNext(ClientConnectionDelegate$createSessionDelegate_6052335267724906805.java)
            18:17:52,375 INFO [STDOUT] at org.jboss.jms.client.delegate.ClientConnectionDelegate.createSessionDelegate(ClientConnectionDelegate.java)
            18:17:52,375 INFO [STDOUT] at org.jboss.jms.client.JBossConnection.createSessionInternal(JBossConnection.java:269)
            18:17:52,375 INFO [STDOUT] at org.jboss.jms.client.JBossConnection.createXASession(JBossConnection.java:198)
            

            (We are using EAP 4.3.0)

            May someone help us to understand what's wrong with this method?

            If we create again a new XAConnection on the same JBM cluster, we do not get the same XARessource (i.e. our Xid is not recognized when doing the JOIN).

            Is it possible to get back an XARessource that accept the Xid we declared in the failed node?



            olivier



            • 3. Re: Opening a new JMS session for an already existing transa
              Clebert Suconic Master

              The NPE seems some classPath issue on trying to install the AOP.

              • 4. Re: Opening a new JMS session for an already existing transa
                olivier motelet Newbie

                May you please elaborate on the classpath error?

                It seems that the state of the connectionState of the clientConnectionDelegate of the XAConnection is null.

                connectionState does not appear to be serializable.

                Does that mean that the same XAConnection cannot be shared between the nodes?

                If it is the case, how can we obtain an XARessource that accept the Xid we declared in the failed node?


                thx
                olivier

                • 5. Re: Opening a new JMS session for an already existing transa
                  Clebert Suconic Master

                  It seems that something didn't work correctly while installing the aspects on your client. I have seen that when users didn't follow version recommendations (AOP on client for instance) or missing other libraries.

                  • 6. Re: Opening a new JMS session for an already existing transa
                    olivier motelet Newbie

                    The client is a webapp running on the server hosting JBM.

                    We tried to add the aop libs inside the /lib of our server folder.
                    Nothing better...