1 2 Previous Next 15 Replies Latest reply on Apr 10, 2008 3:06 AM by Jesper Pedersen

    JBPAPP-750 - Integration between AS and JBossMessaging 1.4

    Jesper Pedersen Master

      I'm currently looking at

      http://jira.jboss.com/jira/browse/JBPAPP-750

      with the integration between the EAP and JBossMessaging since JBM implements both the non-XA and XA interfaces. XA mode is selected at session level.

      1)
      Is the best way to handle this to extend the JmsConnectionRequestInfo class
      with XA information - f.ex. UseXA - and then use this information when
      creating the sessions in JmsManagedConnection::setup() ?

      Of course there will be other changes also JmsMCFProperties, ... Creating
      f.ex. a JmsXASession class may be an idea.

      2)
      JmsActivation also need information about XA from JmsActivationSpec in order to create the correct connection type - so UseXA here.

      Any feedback on how this should be done is most welcome

        • 1. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
          Adrian Brock Master

           

          "jesper.pedersen" wrote:
          I'm currently looking at

          http://jira.jboss.com/jira/browse/JBPAPP-750

          with the integration between the EAP and JBossMessaging since JBM implements both the non-XA and XA interfaces. XA mode is selected at session level.

          1)
          Is the best way to handle this to extend the JmsConnectionRequestInfo class
          with XA information - f.ex. UseXA - and then use this information when
          creating the sessions in JmsManagedConnection::setup() ?

          Of course there will be other changes also JmsMCFProperties, ... Creating
          f.ex. a JmsXASession class may be an idea.


          No. XA or local is a property of the connection factory deployment not the request.


          2)
          JmsActivation also need information about XA from JmsActivationSpec in order to create the correct connection type - so UseXA here.

          Any feedback on how this should be done is most welcome


          If you can't determine the type from the real ConnectionFactory
          then there's no portable way for you to determine what
          type of jca deployment you are in. The current jms resource adapter
          assumes the connection factory in the jms provider is consistent with the
          connection manager choice.

          This is just a testsuite issue (the idea is to test local only jms connection usage).

          A simple fix (in the testsuite) would be to create a wrapper connection factory that
          * only implements the non xa interfaces
          * delegates to the real connection factory
          * bind it into jndi with a different name
          * create a LocalJMSProvider using that wrapper for the test

          • 2. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
            Jesper Pedersen Master

            Thank you for your feedback, Adrian !

            I'll update the testsuite with the solution you describe.

            • 3. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
              Adrian Brock Master

              I'm just about to do it in JBoss5 so you can copy it back when I've finished.

              • 4. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
                Jesper Pedersen Master

                You are on fire :)

                I'll copy the implementation to EAP branch...

                • 5. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
                  Adrian Brock Master

                  Ok here's the patch
                  http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=rev&revision=71792

                  NOTE: Because JBoss Messaging has a default limit of only 10 message deliveries
                  I had to change the stress test to only run 5 iterations.
                  This needs revisiting. i.e. we aren't going to reproduce the race condition (if it reoccurs)
                  with only 5 iterations.
                  See the FIXME in the test.
                  http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/testsuite/src/main/org/jboss/test/jca/test/ExecuteJMSDuringRollbackStressTestCase.java?r1=71792&r2=71791&pathrev=71792

                  • 6. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
                    Vicky Kak Master

                     

                    "adrian@jboss.org" wrote:

                    A simple fix (in the testsuite) would be to create a wrapper connection factory that
                    * only implements the non xa interfaces
                    * delegates to the real connection factory
                    * bind it into jndi with a different name
                    * create a LocalJMSProvider using that wrapper for the test

                    Rather than having these changes being a part of testsuite I think they should be part of jms/jca as this would eventually make jms/jca as generic resource adapter.


                    • 7. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
                      Adrian Brock Master

                       

                      "vickyk" wrote:

                      Rather than having these changes being a part of testsuite I think they should be part of jms/jca as this would eventually make jms/jca as generic resource adapter.


                      Why? What's the use case?

                      The testsuite use case is to emulate a jms server that doesn't support XA
                      using JBoss Messaging that does. :-)

                      • 8. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
                        Vicky Kak Master

                         

                        "adrian@jboss.org" wrote:

                        Why? What's the use case?


                        I am considering the following jsp as the use case , it contains the similar code what was present in the testcase that failed ;)

                        <%@page import="javax.naming.*,javax.jms.*,org.jboss.tm.TransactionManagerLocator,javax.transaction.*,org.jboss.tm.TxUtils"%>
                        <%
                         Queue queue = (Queue) new InitialContext().lookup("queue/testQueue");
                         ConnectionFactory cf = (ConnectionFactory) new InitialContext().lookup("java:TestJmsLocal");
                         TransactionManager tm = TransactionManagerLocator.getInstance().locate();
                         tm.begin();
                        
                         try
                         {
                         out.println(tm.getTransaction()+"Transaction status --->"+TxUtils.getStatusAsString(tm.getTransaction().getStatus())+"<br>");
                         Connection c = cf.createConnection();
                         out.println(tm.getTransaction()+"Transaction status --->"+TxUtils.getStatusAsString(tm.getTransaction().getStatus())+"<br>");
                         try
                         {
                         c.start();
                         out.println(tm.getTransaction()+"Transaction status --->>>>>>>>"+TxUtils.getStatusAsString(tm.getTransaction().getStatus())+"<br>");
                         Session s = c.createSession(true, Session.SESSION_TRANSACTED);
                        
                         out.println(tm.getTransaction()+"Transaction status -------->"+TxUtils.getStatusAsString(tm.getTransaction().getStatus())+"<br>");
                         }
                         finally
                         {
                         try
                         {
                         c.close();
                         }
                         catch (Exception ignored)
                         {
                         }
                         }
                         }
                         finally
                         {
                         out.println(tm.getTransaction()+"Transaction status --->"+TxUtils.getStatusAsString(tm.getTransaction().getStatus())+"<br>");
                         try{
                         tm.commit();
                         }
                         catch(Exception exp)
                         {
                         out.println("EXP is "+exp+"caused by: "+exp.getCause());
                         exp.printStackTrace();
                         }
                         out.println(tm.getTransaction());
                         }
                        %>


                        Should the above jsp work for the following CF definition ?
                        <tx-connection-factory>
                         <jndi-name>TestJmsLocal</jndi-name>
                         <rar-name>jms-ra.rar</rar-name>
                         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
                         <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
                         <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/TestJMSLocalProvider</config-property>
                         <max-pool-size>20</max-pool-size>
                         <application-managed-security/>
                         </tx-connection-factory>



                        • 9. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
                          Adrian Brock Master

                           

                          "vickyk" wrote:

                          Should the above jsp work for the following CF definition ?
                          <tx-connection-factory>
                           <jndi-name>TestJmsLocal</jndi-name>
                           <rar-name>jms-ra.rar</rar-name>
                           <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
                           <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
                           <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/TestJMSLocalProvider</config-property>
                           <max-pool-size>20</max-pool-size>
                           <application-managed-security/>
                           </tx-connection-factory>



                          Only if TestJMSLocalProvider points at a plain ConnectionFactory, i.e.
                          one that doesn't implement XAConnectionFactory.

                          If the jms provider implements XA then don't use a local connection manager
                          to manage transactions. You end up with the weaker Last Resource Gambit
                          (i.e. the transaction observer pattern rather than the transaction participant pattern).

                          But I'm just repeating what I've already said.

                          I want a real use case not trying to support some broken/stupid configuration.

                          • 10. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
                            Adrian Brock Master

                             

                            "adrian@jboss.org" wrote:
                            You end up with the weaker Last Resource Gambit
                            (i.e. the transaction observer pattern rather than the transaction participant pattern).
                            ...
                            I want a real use case not trying to support some broken/stupid configuration.


                            The testsuite is only a use case because I trying to test the weaker semantics
                            don't have the race condition.

                            • 11. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
                              Tim Fox Master

                               

                              "adrian@jboss.org" wrote:

                              Only if TestJMSLocalProvider points at a plain ConnectionFactory, i.e.
                              one that doesn't implement XAConnectionFactory.

                              If the jms provider implements XA then don't use a local connection manager
                              to manage transactions. You end up with the weaker Last Resource Gambit
                              (i.e. the transaction observer pattern rather than the transaction participant pattern).

                              But I'm just repeating what I've already said.

                              I want a real use case not trying to support some broken/stupid configuration.


                              IMO if the user wants to configure the connection manager for local only, then that's what should happen.

                              The user may have reasons for doing this, like they specifically don't want to use XA, e.g. if there is a known bug in the provider's XA implementation and they need to roll back to local tx as a workaround.

                              So I won't necessarily consider this to be broken configuration.

                              What shouldn't happen is the system silently fails in subtle ways, as it does now.

                              Inferring whether the user wants to use XA on the basis of whether the CF implements the XA CF interfaces is not valid - there's nothing in the spec that says the the same class can't implement both the XA and non XA interfaces.

                              *** Tim dons hard hat in preparation for brocking

                              • 12. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
                                Adrian Brock Master

                                 

                                "timfox" wrote:
                                What shouldn't happen is the system silently fails in subtle ways, as it does now.

                                Inferring whether the user wants to use XA on the basis of whether the CF implements the XA CF interfaces is not valid - there's nothing in the spec that says the the same class can't implement both the XA and non XA interfaces.


                                Like I said above. There's no way for the resource adapter to know that the administrator
                                configured a local connection manager. So there's no way for us avoid the
                                subtle failures when things get misconfigured.

                                ASIDE

                                Well actually there is, you can try to make the **guess** based on whether
                                getXAResource()/getLocalTransaction() or nothing was invoked,
                                but you'd have to jump through a lot of hoops to delay initializing the connection
                                for as a long as possible so you can decide which api to use based on that call.

                                END-ASIDE

                                I don't consider a "workaround" a real use case.
                                We could add all sorts of config options to enable users to workaround potential
                                bugs in other peoples code.

                                But the YAGNI princple applies.
                                i.e. We'll do it when we really have to, e.g. all the Oracle jdbc driver workarouds we have.
                                Otherwise lets not over complicate the configuration with useless options which
                                only means the users can't see the wood for the trees.

                                • 13. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
                                  Tim Fox Master

                                   

                                  "adrian@jboss.org" wrote:

                                  Like I said above. There's no way for the resource adapter to know that the administrator
                                  configured a local connection manager. So there's no way for us avoid the
                                  subtle failures when things get misconfigured.


                                  With the current configuration, yes. I accept no-one wants to introduce config changes for AS 4.x right now.

                                  But for JBoss 5, how about making an explicit distinction between the QueueFactoryRef and the XAQueueFactoryRef etc.

                                  (Looking at the glassfish jms ra config I can see they allow them to be specified separately.)

                                  • 14. Re: JBPAPP-750 - Integration between AS and JBossMessaging 1
                                    Adrian Brock Master

                                     

                                    "timfox" wrote:

                                    But for JBoss 5, how about making an explicit distinction between the QueueFactoryRef and the XAQueueFactoryRef etc.


                                    Or even something as simple as a "UseXA" on the JMSProvider config.
                                    But its still going to fail when it is configured inconsistently.

                                    If I thought there really was a use case, then we could create
                                    a simpler
                                    <jms-connection-factory/>
                                    xml tag like we do
                                    for datasources in the -ds.xml which would avoid the misconfiguration.

                                    Maybe the misconfiguration problem is actually the use case that I'm looking
                                    for to justify spending time on this?

                                    1 2 Previous Next