8 Replies Latest reply on Jun 16, 2010 3:41 AM by Tomohisa igarashi

    Additional management API about prepared transaction

    Tomohisa igarashi Master

      Hello, I'm considering about managing prepared transaction in HornetQ.

      HornetQ already has listPreparedTransactions(), but it returns Xid and creation time only. In some trouble case, operator want to know more about the transaction before decide to commit or rollback. For example, message header, message payload, and etc..

      So, I think implementing following additional APIs into HornetQServerControl is nice:

      ----

      • listPreparedTransactionsAsHTML()
        • Show Xid(separeted field in global_txid, branch_qual, format_id, ..), creation time(or elapsed time) and message_id as HTML format.
      • listPreparedTransactionsAsXML()
        • Same as listPreparedTransactionsAsHTML(), but in XML format. That will used by another external program.
      • getMessageDetails( int message_id )
        • Return some object represents message with read only. That will used by another internal program.
      • showMessageDetailsAsHTML( int message_id )
        • Show status(send committed/send prepared/receive prepared), destination name, message header and message payload In addition to same as listPreparedTransactions' output, as HTML format.
      • showMessageDetailsAsXML( int message_id )
        • Same as showMessageDetailsAsHTML(), but as XML format. That will used by another external program.

      ----

      Any suggestions would be appreciated.

       

      Thanks

      Tomohisa Igarashi

        • 1. Re: Additional management API about prepared transaction
          Tomohisa igarashi Master

          I'm trying to find how to access the message contents(ex. payload) which is under prepared transaction from Xid, but it has not been found yet, except reading all journal record from beginning. Is there any other way ?

           

          Would you give me some advice ?

           

          I'll read Compactor implementation which may have some hints.

           

          ----

          Thanks

          igarashitm

          • 2. Re: Additional management API about prepared transaction
            Tomohisa igarashi Master

            I found PostOfficeImpl$AddOperation and QueueImpl$RefsOperation had a list of related MessageReference, and TransactionImpl has its own list of related TransactionOperation. So we can reach the message contents which is related to the transaction from Xid, if we can touch that field. However, these are now private and we can't touch them without reflection API.

             

            two solutions:

            1. Create getter on TransactionImpl and TransactionOperation interface
              1. List<TransactionOperation> org.hornetq.core.transaction.impl.TransactionImpl#getAllOperations()
              2. List<MessageReference> org.hornetq.core.transaction#getRelatedReferences()
            2. Make AddOperation and RefsOperation classes public. And create getter on these two classes and TransactionImpl
              1. List<TransactionOperation> org.hornetq.core.transaction.impl.TransactionImpl#getAllOperations()
              2. List<MessageReference> org.hornetq.core.transaction.impl.operation.AddOperation#getRelatedReferences()
              3. List<MessageReference> org.hornetq.core.transaction.impl.operation.RefsOperation#getRelatedReferences()

             

            I think 2nd solution is better because other TransactionOperation classes may not have MessageReference. (ex. org.hornetq.core.postoffice.impl.DuplicateIDCacheImpl$AddDuplicateIDOperation)

             

            Would you give me any suggestion? If you agree with 2nd solution, I'll raise a JIRA and attach a patch.

             

            ----

            Thanks,

            igarashitm

            • 3. Re: Additional management API about prepared transaction
              Clebert Suconic Master

              What about adding a toString() on each TransactionOperation,

               

              and you could add a methodon TransactionOperation to expose the MessageReferences. You would return null or empty for the cases where you don't have a reference (example: AddDuplicateID)

               

              TransactionOperation is a public class, on this case you can keep the implementations as private.

              • 4. Re: Additional management API about prepared transaction
                Tomohisa igarashi Master

                Hello Clebert,

                 

                Thanks for your advice!

                 

                I like implementing getter of MessageReference on TransactionOperation, because toString() should fix String expression.

                I've raised a JIRA and attached a patch. I'm happy if you pull it to the HornetQ.

                https://jira.jboss.org/browse/HORNETQ-405

                 

                Thanks,

                igarashitm

                • 5. Re: Additional management API about prepared transaction
                  Clebert Suconic Master

                  So far you have created the methods to expose the messages on their respective transactions.

                   

                  Are you still creating the method helpers on management to print the transaction detailed? Such as listTransactionDetailsAsHTML and listTransactionDetailsMaybe on HornetQServerControl?

                   

                  If you do that, then the task willl be complete.

                   

                   

                  I believe you need something like that:

                   

                   

                  HornetQServerControl::listTransactionDetails(String XIDrepresentation)

                   

                  Transaction tx = findTXSomehow(....); // the other methods are doing that

                   

                  for (Operation operation: tx.getOperation())

                  {

                     outputString.println(operation.toString());

                     for (MessagRef ref: messagesOnTx)

                     {

                         /// print some info about the message.

                     }

                  }

                  • 6. Re: Additional management API about prepared transaction
                    Tomohisa igarashi Master

                    Hello Clebert,

                     

                    oops, forgot to mention about that...Thanks for your suggestion.

                    OK, I'll implement the listTransactionDetailsAsHTML() and  listTransactionDetails() and re-attach a patch including getter method(I attached last day).

                    • 7. Re: Additional management API about prepared transaction
                      Clebert Suconic Master

                      It would be nice to have some unit testing also. (At least to make sure the method won't fail). That's probably an easy one.

                      • 8. Re: Additional management API about prepared transaction
                        Tomohisa igarashi Master

                        Hello Clebert,

                         

                        Sorry to be late. Attached new one.

                        https://jira.jboss.org/secure/attachment/12334997/listPreparedTransactionDetails.svndiff

                         

                        ----

                        • Add following operations to HornetQServerControl. Payload representation  is *NOT* included in the output of these method.
                          • TranscationDetailDTO[] getPreparedTransactionDetails()
                          • String[] listPreparedTransactionDetails()
                          • String listPreparedTransactionDetailsAsHTML()
                        • And also add following operations to JMSServerControl. The output  includes payload representation.
                          • String[] listPreparedTransactionDetails()
                          • String listPreparedTransactionDetailsAsHTML()
                        • Add some testcases

                        ----

                         

                        Could you consider to merge this into HornetQ?