4 Replies Latest reply on Mar 12, 2010 2:56 PM by clebert.suconic

    ReaperThread bug ?

    clebert.suconic

      I'm having an issue on HornetQ's integration on the application server, as I posted here:

       

      http://community.jboss.org/thread/149374?tstart=0

       

       

      I will basically copy what I had originally on the Hornetq's dev forum:

       

       

      It appears to be a bug:

       

       

      I have my user transaction (javaee user transaction) setting the timeout to 5 seconds:

       

       

               UserTransaction ut = sessionCtx.getUserTransaction();

               ut.setTransactionTimeout(5);

               ut.begin();

      My test is doing some things and waiting 10 seconds:
                   
                     log.info("Received first message!");
                     log.info("Waiting 10 seconds now!");
                     try
                     {
                        Thread.sleep(10000);
                     }
                     catch (InterruptedException ignored)
                     {
                     }
      For some reason, the transaction is finishing ok.
      I debugged this and HornetQRAXAresource is receiving and end(...Success).
      The reaper thread on the Transaction manager is calling TransactionReapper.doCancellations...
      a few calls later, XAResourceRecord.topLevelAbort will call this:
                          try
                          {
                               if (!_prepared)
                               {
                                    if (endAssociation())
                                    {
                                         _theXAResource.end(_tranID, XAResource.TMSUCCESS);
                                    }
                               }
                          }
       
       
       
       
      

       

       

       

      The only reason this is working with the current resource adapter is because the resource adapter is checking for the status on the userTransaction object on every operation. But the TransactionManager should call the proper end here with the abort status IMO.

       

       

      This could be replicated by the test org.jboss.test.jca.test.TransactionActiveUnitTestCase on the HornetQ integration branch on the application server's SVN.

        • 1. Re: ReaperThread bug ?
          jhalliday
          Whilst it's not optimal it's not a bug either. The flag to end refers to the work on the branch rather than to the tx outcome. The sequence end(success); rollback(); is valid and will occur not only from the reaper timeout but also in a normal tx termination where a prepare on another resource fails and the tm executes a rollback. Therefore, whilst we could change the reaper (and the normal rollback path, which is largely the same) to use end(fail), your code is going to have to cope with end(success); rollback() anyhow.
          • 2. Re: ReaperThread bug ?
            clebert.suconic

            The problem is that the TM is calling commit() through topLevel somehow.

             

            And it's weird that the client is getting a can't commit exception but the resource.commit() was already called by the time the exception was caught.

            • 3. Re: ReaperThread bug ?
              clebert.suconic

              Scratch what I said about the commit being called anyway. I will do some debug and provide some input in 10 minutes.

               

               

              There's definitely something weird going on though.

              • 4. Re: ReaperThread bug ?
                clebert.suconic

                Ok, I see what you mean. Rollback is being called properly.

                 

                The bug is probably on HornetQ then. i will investigate a bit more. I will come back later if I see any other thing wrong about this.

                 

                 

                Thanks for the help

                 

                 

                Clebert