1 2 Previous Next 29 Replies Latest reply on Dec 10, 2006 10:22 AM by Juha Lindfors

    Branch 1_0_XARecovery

    Juha Lindfors Master

      Just a FYI.

      The branch exists temporarily for 1.0.x series XA recovery code until fully completed, tested and integrated.

        • 1. Re: Branch 1_0_XARecovery
          Ovidiu Feodorov Master

          OK. Please update http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingMergingActivity so we know at any time the branching situation.

          • 2. Re: Branch 1_0_XARecovery
            Juha Lindfors Master

            FYI,

            Branch XA_Recovery adds build dependency to JBossTM.

            Also, release-admin has been modified to create a configuration that replaces the AS local TM with JBossTS implementation. For that purpose the build creates a jboss-messaging-integration.jar that contains the relevant integration class implementations.

            The integration only works with AS 4.0.5.GA. The release-admin needs to be modified to create specific configs for 4.0.4.GA and 4.0.3.SP1

            • 3. Re: Branch 1_0_XARecovery
              Ovidiu Feodorov Master

              One observation: people use the release-admin script as default installer for JBoss 4.x. Replacing the transaction manager is a pretty big step for a production installation, so we should give them a chance to opt out, and document this very well.

              Some may not need the XA recovery feature, and happily live without complications caused by replacing the TM, so I would do this as follows: running the script with the default parameters (none) would create the "old", non-XA-recovery-enabled configuration, running it with -xa-recovery (or something) would perform the full installation.

              This will become irrelevant in 4.2 and 5, but we need to be careful about the existing installed base.

              I would create a JIRA issue and work on this for 1.0.2, unless you have objections. Not needed for 1.2.0.Beta.

              • 5. Re: Branch 1_0_XARecovery
                Juha Lindfors Master

                 

                "ovidiu.feodorov@jboss.com" wrote:


                I would create a JIRA issue and work on this for 1.0.2, unless you have objections. Not needed for 1.2.0.Beta.


                No objections.


                • 6. Re: Branch 1_0_XARecovery
                  Juha Lindfors Master

                  FYI,

                  Branch_1_0_XARecovery introduces a tight coupling between TransactionRepository and the currently configured MessageStore service. This is set up by the ServerPeer at startup.

                  • 7. Re: Branch 1_0_XARecovery
                    Tim Fox Master

                     

                    "juha@jboss.org" wrote:
                    FYI,

                    Branch_1_0_XARecovery introduces a tight coupling between TransactionRepository and the currently configured MessageStore service. This is set up by the ServerPeer at startup.


                    I think this is correct.

                    The message store used by transaction repository should always be the same as the one used by server peer, therefore it wouldn't be appropriate for it to be configured as a separate mbean dependency (for example), so injecting it from server peer sounds right to me.

                    This is current how the persistence manager dependency is injected too for the same reasons.

                    • 8. Re: Branch 1_0_XARecovery
                      Juha Lindfors Master

                      FYI,

                      There's another slightly more subtle API change in JDBCPersistenceManager where retrievePreparedTransactions used to return List <Xid,> now returns List <PreparedTxInfo,>

                      PreparedTxInfo is basically a pair <LocalTxId, Xid>.

                      • 9. Re: Branch 1_0_XARecovery
                        Tim Fox Master

                        Sounds reasonable

                        • 10. Re: Branch 1_0_XARecovery
                          Juha Lindfors Master

                          FYI,

                          XARecoveryTest has been re-enabled in the unit test suite.

                          • 11. Re: Branch 1_0_XARecovery
                            Juha Lindfors Master

                            FYI,

                            MessagingXAResource has been modified to recreate incoming Xids with messaging's own implementation to avoid conflicting xid instances ending up in the internal global-to-local transaction map. See JBMESSAGING-661 for details.

                            The current state of XARecovery branch is what is going to get merged to Branch 1.0 for Messging 1.0.2 beta release.

                            • 12. Re: Branch 1_0_XARecovery
                              Tim Fox Master

                              Juha-

                              I have a few questions on the current implementation in svn:

                              1) The call to persistenceManager.associateTxCallbackToPreparedTx() in TransactionRepository::loadPreparedTransactions()

                              seems to be redundant since the callback will be automatically created when the refs / acks are replayed.

                              2) TransactionRepository::handleReferences():

                              call to persistenceManager.getMessageIdForRef(txId)

                              you only seem to be returning the first message id, the transaction may contain many message adds - so
                              you need to retrieve them all.

                              you need to do the following:

                              3) TransactionRepository::handleAcks():

                              same problem as for 2)

                              • 13. Re: Branch 1_0_XARecovery
                                Juha Lindfors Master

                                 

                                "timfox" wrote:

                                1) The call to persistenceManager.associateTxCallbackToPreparedTx() in TransactionRepository::loadPreparedTransactions()

                                seems to be redundant since the callback will be automatically created when the refs / acks are replayed.


                                However, removing it will cause the recovery to fail (messages are not delivered).

                                So if you think it is redundant then that failure to work correctly without the call needs to be investigated. That's why I've kept the related JIRA task on this still open.


                                "timfox" wrote:


                                2) TransactionRepository::handleReferences():

                                call to persistenceManager.getMessageIdForRef(txId)

                                you only seem to be returning the first message id, the transaction may contain many message adds - so
                                you need to retrieve them all.


                                Right. I was suspecting this based on the API but couldn't find any clear indication of this in the code.


                                • 14. Re: Branch 1_0_XARecovery
                                  Tim Fox Master

                                   

                                  "juha@jboss.org" wrote:
                                  "timfox" wrote:

                                  1) The call to persistenceManager.associateTxCallbackToPreparedTx() in TransactionRepository::loadPreparedTransactions()

                                  seems to be redundant since the callback will be automatically created when the refs / acks are replayed.


                                  However, removing it will cause the recovery to fail (messages are not delivered).



                                  Should definitely be redundant. If stuff fails when it's removed, then that points to another problem.

                                  "Juha" wrote:

                                  Right. I was suspecting this based on the API but couldn't find any clear indication of this in the code.


                                  What you want to do is basically this:

                                  for the acks:

                                  select message_id from jms_message_reference where transaction_id=? and state ="+"

                                  this gives you all the message ids you want to load

                                  then call persistenceManager.getMessages(List ids) to get the actual messages for those ids.

                                  Then call messageStore.reference(Message m) for each of those messages - this will give you a reference for each of the messages.

                                  Once you have your references you can call channel.handle(ref, tx) to replay them through the channel.

                                  (This will create any callbacks).

                                  A similar procedure applies for acks, except the query to get them is different:

                                  select message_id from jms_message_reference where transaction_id=? and state ="-"



                                  1 2 Previous Next