4 Replies Latest reply on May 24, 2013 9:42 AM by byamabe

    4.2.2 JTA Port Bindings

    byamabe

      I am configuring the TransactionManagerService with the following block in jboss-service.xml:

       

          <!-- JBoss Transactions JTA -->

         <mbean code="com.arjuna.ats.jbossatx.jta.TransactionManagerService"

            name="jboss:service=TransactionManager">

            <attribute name="TransactionTimeout">3600</attribute>

            <attribute name="ObjectStoreDir">${jboss.server.data.dir}/tx-object-store</attribute>

         </mbean>

       

      I am getting 3 addition ports anonymously/dynamically bound when this configuration is enabled.

      I believe one is the JBossTS Recovery Manager port and another is the JBossTS Transaction Status Manager port.

       

      Does anyone know what the third port is and if there is a way to configure these ports to be bound to a specific port number?

        • 1. Re: 4.2.2 JTA Port Bindings
          tomjenkinson

          Hi Brian,

           

          To configure the sockets you should be able to use:

           

          com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort

          com.arjuna.ats.internal.arjuna.recovery.recoveryPort

           

          I say "should" as 4.2.2 is ancient and I haven't a build to fire up atm.

           

          I am not sure what the third socket is, I thought it was the socket process id one but looking at the 4.2.3 code this would be using the same as the TSM socket (it is used to guarantee a unique port on the node, not read/written to), unless somehow the TSM is started before SocketProcessId is, in which case it will still pick a random new port. Setting com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort will actually verify that as that property changes the default (of 0) for both socketprocessid and TSM.

           

          Tom

          • 2. Re: 4.2.2 JTA Port Bindings
            byamabe

            Tom,

            Thanks so much for your helpful answer!

             

            Setting the property com.arjuna.ats.internal.arjuna.recovery.recoveryPort in jbosstja-properties.xml worked!

             

                <property name="com.arjuna.ats.internal.arjuna.recovery.recoveryPort" value="5555"/>

             

            Setting com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort had no effect

             

                <property name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort" value="4444"/>

             

            I did find the issue titled "Enable Setting Port with com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort" which was reported in 4.2.3 and resolved .in 4.4. It looks like this would enable that configuration and is related to the socket process id code you see.

             

            Tom, as follow up, is the socket process id port configurable as well?

             

            Thanks again,

            Brian

            • 3. Re: 4.2.2 JTA Port Bindings
              tomjenkinson

              Hi Brian,

               

              Glad I could help, you can certainly configure the socket id independently in later versions, it appears this was introduced in 4.4 (https://anonsvn.jboss.org/repos/labs/labs/jbosstm/tags/JBOSSTS_4_4_0_GA/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/SocketProcessId.java)

               

              Integer port = Utility.lookupBoundedIntegerProperty(arjPropertyManager.propertyManager, Environment.SOCKET_PROCESS_ID_PORT, _defaultPort,

                                      "com.arjuna.ats.internal.arjuna.utils.SocketProcessId_1",

                                      0, Utility.MAX_PORT);

               

              Is there a reason you are not able to use a later version of JBoss Transactions?

               

              Thanks,
              Tom

              1 of 1 people found this helpful
              • 4. Re: 4.2.2 JTA Port Bindings
                byamabe

                Tom,

                Thanks for the information on socket id configurability.

                 

                Long, convoluted story as to why we never moved passed 4.2.2, but thanks to your help I think I can make the case that 4.4 is a good short-term option and moving to a modern release would be a good long-term strategy.

                 

                Thanks,

                Brian