1 3 4 5 6 7 Previous Next 96 Replies Latest reply on Jun 14, 2010 6:20 PM by clebert.suconic Go to original post
      • 90. Re: Regression on AS6 org.jboss.test.jca.test.TransactionActiveUnitTestCase
        ataylor

        Roll back the changes for dual sessions, change the serversession to allow non xa calls. This will break the XA tests and Jeff and I will look at a solution tomorrow. I think thats what was decided. If you want create a branch for now

        • 91. Re: Regression on AS6 org.jboss.test.jca.test.TransactionActiveUnitTestCase
          clebert.suconic

          I have over the weekend added a new test to the AS that will translate the situation on TCK.

           

          One test is validating the "dual session" behaviour is in place. i.e. We will accept sends and ACKs as non-transactioned when not enlisted.

           

           

          public void emptyRollback()
             {
                 try
                 {
                     InitialContext ctx = new InitialContext();
                     ConnectionFactory cf = (ConnectionFactory) ctx.lookup("java:JmsXA");
                     javax.jms.Connection c = cf.createConnection();
              
                     Session s = c.createSession(false, Session.AUTO_ACKNOWLEDGE);
                     Queue queue = (Queue) ctx.lookup("/queue/A");
          
                     UserTransaction ct = sessionCtx.getUserTransaction();
                     ct.begin();
                     ct.rollback();
                     
                     MessageProducer prod = s.createProducer(queue);
                     
                     prod.send(s.createMessage());
                     
                     c.close();
                     
                 }
                 catch (Exception e)
                 {
                     throw new RuntimeException(e.getMessage(), e);
                 }
             }
          
          
          

           

          Basically, the test will open a transaction, close it regularly and send the result to the client. Another class will validate if the send here happened properly.

           

           

           

          The second is the test that was already there, which will validate the timeout:

           

           

           

          
          
          public void changeQueue()
             {
                try
                {
                   InitialContext ctx = new InitialContext();
                   Queue queue = (Queue) ctx.lookup("queue/testQueue");
                   UserTransaction ut = sessionCtx.getUserTransaction();
                   ut.setTransactionTimeout(5);
                   ut.begin();
                   try
                   {
                      ConnectionFactory cf = (ConnectionFactory) ctx.lookup("java:JmsXA");
                      javax.jms.Connection c = cf.createConnection();
                      try
                      {
                         c.start();
                         Session s = c.createSession(true, Session.SESSION_TRANSACTED);
                         MessageConsumer mc = s.createConsumer(queue);
                         TextMessage txt = (TextMessage)mc.receive(5000);
                         if (!txt.getText().equals("101"))
                         {
                            throw new IllegalStateException("Unexpected message content. It should be 101");
                         }
                         if (mc.receiveNoWait() != null)
                         {
                            throw new IllegalStateException("Didn't expect two messages");
                         }
                         mc.close();
                         try
                         {
                            Thread.sleep(10000);
                         }
                         catch (InterruptedException ignored)
                         {
                         }
                         
                         try
                         {
                            MessageProducer p = s.createProducer(queue);
          
                            Message m = s.createTextMessage("100");
                            p.send(m);
                         }
                         catch (JMSException expected)
                         {
                         }
                      }
                      finally
                      {
                         try
                         {
                            c.close();
                         }
                         catch (Exception ignored)
                         {
                         }
                      }
                   }
                   finally
                   {
                      try
                      {
                         ut.commit();
                      }
                      catch (Exception ignored)
                      {
                      }
                   }
                }
                catch (RuntimeException e)
                {
                   throw e;
                }
                catch (Exception e)
                {
                   throw new RuntimeException("Unexpected Error: ", e);
                }
             }
          
          

           

           

           

          I don't know how to make a distinction between the first and the second case. The TM will send me a End(Success) and rollback on both cases. There's no difference for us.

           

          ATM: the only way to validate if there's still a pending TX is by asking the TM.

          • 92. Re: Regression on AS6 org.jboss.test.jca.test.TransactionActiveUnitTestCase
            timfox

            You mention both of these tests are derived from TCK tests.

             

            Can you send me the code of the original TCK tests from which the two tests are derived? I would like to take a look at them both.

            • 93. Re: Regression on AS6 org.jboss.test.jca.test.TransactionActiveUnitTestCase
              clebert.suconic
              emptyRollback is derived from the TCK. I will send you a snippet in a private mail.

              TCK doesn't do any tests on timed out sessions. (not for JMS at least).
              • 94. Re: Regression on AS6 org.jboss.test.jca.test.TransactionActiveUnitTestCase
                timfox

                "TCK doesn't do any tests on timed out sessions. (not for JMS at least)."

                 

                This is exactly my point. So why do you think the test is valid? Is it just a test that you made up?

                 

                I'll go through it once again.

                 

                Really slowly this time.

                 

                1) Revert code to get AS test suite passing 100% like we had after AS6 integration.

                 

                2) Now we deal with TCK. Now, you just said that the transaction timeout is not tested by the TCK, so that's not a problem. The other test will pass fine once we revert

                • 95. Re: Regression on AS6 org.jboss.test.jca.test.TransactionActiveUnitTestCase
                  clebert.suconic

                  No, I didn't make up the session. It's an old test and it's there since JBoss 3.

                   

                  It's not possible to get the Testsuite to pass 100% without fixing the timeout issue properly.

                   

                  I just need to know how we can get to know when a timeout happened without using the TM.

                   

                  Transaction timeouts would be useless if didn't take care of it. The test is valid for sure.

                  • 96. Re: Regression on AS6 org.jboss.test.jca.test.TransactionActiveUnitTestCase
                    clebert.suconic

                    to update everybody,

                     

                     

                    We have got into an agreement. We will keep the TM integration but I will remove the cached Session both I and Tim didn't like it.

                     

                     

                    The reason for the cached Session was because of https://jira.jboss.org/browse/HORNETQ-328

                     

                    If I revert 328 (allowing the XAsession to behave as non-transactioned), then we don't need the cached sessions any more.

                    1 3 4 5 6 7 Previous Next