5 Replies Latest reply on Nov 14, 2007 3:44 PM by Chi Nguyen

    JTS warnings/performance issue

    Chi Nguyen Newbie

      We are trying to integrate a J2EE app that encompasses two ears that are on separate JVMs. A common interaction would be session bean A on JVM1 calls session bean B on JVM2 which in turn calls session bean C on JVM1, all in one distributed transaction.

      When we intially ported this from weblogic to JBossAS 4.2.0GA, we noticed that distributed transactions were not being honored. Reading up some more it was due to us not having JTS for JBoss. So we installed JBOSSTS_4_3_0_BETA2 to and configured our app server to use JTS (we followed the install instructions verbatim with the exception that we had to copy over the jacorb.jar that was part of the JTS package to our app server).

      Now when running the app server I see the following warnings:

      2007-10-24 06:44:39,730 WARN [com.arjuna.ats.jts.logging.loggerI18N] [com.arjuna.ats.internal.jts.cwcommit] Failed to mark transaction as rollback only:
      org.omg.CosTransactions.Unavailable: IDL:omg.org/CosTransactions/Unavailable:1.0
      at com.arjuna.ats.internal.jts.ControlWrapper.rollback_only(ControlWrapper.java:344)
      at com.arjuna.ats.internal.jts.ControlWrapper.preventCommit(ControlWrapper.java:168)
      at com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:714)
      at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:91)
      2007-10-24 06:44:39,730 WARN [com.arjuna.ats.jts.logging.loggerI18N] [com.arjuna.ats.internal.jts.cwcommit] Failed to mark transaction as rollback only:
      org.omg.CosTransactions.Unavailable: IDL:omg.org/CosTransactions/Unavailable:1.0
      at com.arjuna.ats.internal.jts.ControlWrapper.rollback_only(ControlWrapper.java:344)
      at com.arjuna.ats.internal.jts.ControlWrapper.preventCommit(ControlWrapper.java:168)
      at com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:714)
      at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:91)
      2007-10-24 06:44:39,730 WARN [com.arjuna.ats.jts.logging.loggerI18N] [com.arjuna.ats.internal.jts.cwcommit] Failed to mark transaction as rollback only:
      org.omg.CosTransactions.Unavailable: IDL:omg.org/CosTransactions/Unavailable:1.0
      at com.arjuna.ats.internal.jts.ControlWrapper.rollback_only(ControlWrapper.java:344)
      at com.arjuna.ats.internal.jts.ControlWrapper.preventCommit(ControlWrapper.java:168)
      at com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:714)
      at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:91)


      Could someone give me insight as to what they mean? Our application seems to be in a consistent state and it is puzzling as to what the TransactionReaper thread is trying to rollback. Is it just an expected warning (we see hundreds of these)?

      Another issue is that our performance has been horrible (10x slower that with just JTA out of the box). Is this expected?

      Thanks in advance.

        • 2. Re: JTS warnings/performance issue
          Chi Nguyen Newbie

          Thanks for your quick response.

          I had seen that url but when I had looked at the JTS4_3_0BETA2 INSTALL document I saw the information below which sort of led me to believe that it *could*work. Can someone update that file to reflect otherwise.

          As to my current predicament, I guess that means I will have to try to run on 4.0.

          Thanks for your help.

          Excerpt of INSTALL document:

          Installing JBossTS 4.4 into JBossAS 4.2
          ------------------------------------------------------------

          Starting with JBossAS 4.2, the application server ships with
          JBossTS JTA as a default component. You do not need to take
          any action if you want JTA support only.


          To change the JTA to the full JTS in JBossAS 4.2, follow these steps:

          • 3. Re: JTS warnings/performance issue
            Chi Nguyen Newbie

            jhalliday I downgraded my jbossas to 4.0.5 and 4.2.3sp7 JTS and I am able to get a distributed transaction to rollback correctly. I have a few questions:

            1. I just want to clarify that on my two application server instances I am running the "all" configuration. In my case since I am running on the same host, I just made sure that I had a unique jacorb name and that I made sure that the objectstore was different for both servers. Is this correct?

            2. I read in the release notes that contextPropMode should be set to CONTEXT. But doesn't INTERPOSITION (default) better performing? Which one would you recommend using.

            3. I am seeing the following warnings in my logs, do you have an idea as to what could be going on?

            4. Lastly, it another post you said that ejb transaction inflow does is buggy and does not work. Could you expand on that, is there a jira defect associated with it that I could read up on? (I looked and did not find one that seemed applicable).



            . Returning default value: true
            12:39:03,864 WARN [controller] rid: 1597698 opname: commit cannot process request, because object doesn't exist
            12:39:03,864 WARN [controller] rid: 1597698 opname: commit request rejected with exception:
            12:39:04,317 WARN [controller] rid: 1597848 opname: saveRecord cannot process request, because object doesn't exist
            12:39:04,317 WARN [controller] rid: 1597848 opname: saveRecord request rejected with exception:
            12:39:04,317 WARN [loggerI18N] [com.arjuna.ats.internal.jts.resources.errsavefail] ExtendedResourceRecord.doSave failed
            . Returning default value: true
            12:39:04,411 WARN [controller] rid: 1597874 opname: commit cannot process request, because object doesn't exist
            12:39:04,411 WARN [controller] rid: 1597874 opname: commit request rejected with exception:
            12:39:04,785 WARN [controller] rid: 1598024 opname: saveRecord cannot process request, because object doesn't exist
            12:39:04,785 WARN [controller] rid: 1598024 opname: saveRecord request rejected with exception:
            12:39:04,785 WARN [loggerI18N] [com.arjuna.ats.internal.jts.resources.errsavefail] ExtendedResourceRecord.doSave failed
            . Returning default value: true
            12:39:04,801 WARN [controller] rid: 1598026 opname: saveRecord cannot process request, because object doesn't exist
            12:39:04,801 WARN [controller] rid: 1598026 opname: saveRecord request rejected with exception:
            12:39:04,801 WARN [loggerI18N] [com.arjuna.ats.internal.jts.resources.errsavefail] ExtendedResourceRecord.doSave failed
            . Returning default value: true
            12:39:04,895 WARN [controller] rid: 1598032 opname: commit cannot process request, because object doesn't exist
            12:39:04,895 WARN [controller] rid: 1598032 opname: commit request rejected with exception:
            12:39:04,926 WARN [controller] rid: 1598040 opname: commit cannot process request, because object doesn't exist
            12:39:04,926 WARN [controller] rid: 1598040 opname: commit request rejected with exception:
            12:39:05,254 WARN [controller] rid: 1598312 opname: saveRecord cannot process request, because object doesn't exist
            12:39:05,254 WARN [controller] rid: 1598312 opname: saveRecord request rejected with exception:
            12:39:05,254 WARN [loggerI18N] [com.arjuna.ats.internal.jts.resources.errsavefail] ExtendedResourceRecord.doSave failed
            . Returning default value: true

            • 4. Re: JTS warnings/performance issue
              Jonathan Halliday Master

              > Lastly, it another post you said that ejb transaction inflow does is buggy and does not work.

              Right. The tx context does arrive at the remote server, but then things go bad. There is a point in the AS code where the container asks for the transaction context from the inbound request. Unfortunately it's hardcoded to ask the old JBoss transaction manager, which is no longer used. Hence is does not see the inbound context, which is now managed by JBossTS. It needs to be made pluggable, so that the mechanism by which the inbound tx context is located is configurable at boot time, Then we can have the lookup configured to ask JBossTS, which will give it the right answer. The API changes for this are already in AS trunk, but we are still debating if they will get backported to AS 4.2 branch and/or the EAP 4.2. The fix almost certainly will not be backported to AS 4.0.x.

              http://www.jboss.com/index.html?module=bb&op=viewtopic&t=119099

              • 5. Re: JTS warnings/performance issue
                Chi Nguyen Newbie

                I am really confused by this; I have setup everything on a 4.0.5AS with JTS4.2.3sp7 and it *appears* to be handling ejb transaction context properly. For example if I set rollback only on an ejb in application server 1 then the entire transaction is rolled back (ie. any ejbs that were modified on application server 2 and were part of the same transaction are rolled back too). But from this thread you are saying that would not be the case. Am I just misunderstanding something? If it is truely broken then are you saying that there is no point in me using JTS for ejbs?