4 Replies Latest reply: Mar 12, 2010 2:56 PM by Clebert Suconic RSS

ReaperThread bug ?

Clebert Suconic Master

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 ?
    Jonathan Halliday Master
    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 Master

    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 Master

    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 Master

    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