Uploaded image for project: 'Geronimo'
  1. Geronimo
  2. GERONIMO-5987

The ActiveMQ working directory and port are not referenced correctly - multiple instances not possible

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.0-M1, 3.0.0
    • Fix Version/s: 3.0.0, 3.0-beta-1
    • Component/s: ActiveMQ
    • Security Level: public (Regular issues)
    • Labels:
    • Environment:

      Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga)

      Description

      I am testing with geronimo-tomcat7-javaee6-web-3.0-SNAPSHOT, geronimo-tomcat7-javaee6-web-3.0-20110523.171218-97

      ActiveMQ is configured to run as "org.apache.geronimo.home.dir/var/activemq" and port 61616, and does not cooperate with multi-server configurations, nor does it use the PortOffset. This is the use of the "org.apache.geronimo.server.name" option and PortOffset in "var/config/config-substitutions.properties". (see: https://cwiki.apache.org/GMOxDOC30/running-multiple-geronimo-instances.html)

      First, Problem with working directory
      When wanting to run more than a single server instance, the ActiveMQ startup will block waiting for the lock file "$GERONIMO_HOME/var/activemq/lock" to become available.
      Obviously this causes any server instance started after the first server instance is started to block during startup while waiting for the lock file to become available.

      Second, Problem with PortOffset
      When configuring the PortOffset in "var/config/config-substitutions.properties", all Geroniomo components expect and attempt to connect to ActiveMQ at the port

      {ActiveMQ + PortOffset}

      . However, regardless of what you set the PortOffset to be, the ActiveMQ service only ever binds to port 61616, the default configured port (or whatever you have the port set as for this service).

      Steps to repeat working directory problem:

      1. Download and unpack G3.0 SNAPSHOT (3.0-20110523 tested)

      2. Create the server instances:
      – 2A. cd ${GERONIMO_HOME}
      – 2B-1. mkdir gserver1
      – 2B-2. cp -rp var gserver1/
      – 2B-3. cp -rp etc gserver1/
      – 2B-4. cp -rp repository gserver1/

      3. update the "PortOffset" parameter in gserver1/var/config/config-substitutions.properties for the gserver1 instance.

      4. Start the default instance and gserver1 instance:
      – bin/startup
      – env GERONIMO_OPTS=-Dorg.apache.geronimo.server.name=gserver1 bin/startup

      5. `tail -f gserver1/var/logs/geronimo.log` and you will see this as the last line that outputs:
      "2011-05-31 16:26:39,609 WARN [AMQPersistenceAdapter] Waiting to Lock the Store var/activemq"
      The server waits here indefinitely.

      6. Shutdown the default instance and you will see the "gserver1" instance continue on in the startup procedures. (of course you will see errors due to the PortOffset problem)

      • If I first start the "gserver1" instance by itself (before starting the default instance), the directory "org.apache.geronimo.home.dir/var/activemq" is created and populated. Instead it should be "org.apache.geronimo.home.dir/org.apache.geronimo.server.name/var/activemq" that is created and populated.
      • Probably the patch should be to reference the ActiveMQ working directory as "org.apache.geronimo.server.dir/var/activemq"

      Steps to repeat PortOffset problem:

      1. Download and unpack G3.0 SNAPSHOT (3.0-20110523 tested)

      2. Create the server instances:
      – 2A. cd ${GERONIMO_HOME}
      – 2B-1. mkdir gserver1
      – 2B-2. cp -rp var gserver1/
      – 2B-3. cp -rp etc gserver1/
      – 2B-4. cp -rp repository gserver1/

      3. update the "PortOffset" parameter in gserver1/var/config/config-substitutions.properties in the instance

      4. Start the server instance:
      – env GERONIMO_OPTS=-Dorg.apache.geronimo.server.name=gserver1 bin/startup

      This is the two error messages you receive when configuring PortOffset to 100 (for example). The second error message, regarding XAResource, repeats:
      -
      2011-06-01 16:26:49,883 ERROR [MCFConnectionInterceptor] Error occurred creating
      ManagedConnection for handle: nullManagedConnectionInfo:
      org.apache.geronimo.connector.outbound.ManagedConnectionInfo@1c211b3. mc: null]
      javax.resource.ResourceException: Could not create connection.
      at
      org.apache.activemq.ra.ActiveMQManagedConnectionFactory.createManagedConnection(ActiveMQManagedConnectionFactory.java:171)
      ...
      Caused by: java.net.ConnectException: Connection refused
      ...
      -
      This one reveals the problem that ActiveMQ ia not using PortOffset. RecoveryController wants to connect to ${ActiveMQ + PortOffset} (61616 + 100).
      -
      2011-06-01 16:26:49,885 ERROR [RecoveryController] Recovery error: Could not get
      XAResource for recovery for mcf:
      geronimo:J2EEApplication=null,J2EEServer=geronimo,JCAConnectionFactory=DefaultActiveMQConnectionFactory,JCAManagedConnectionFactory=DefaultActiveMQConnectionFactory,JCAResource=geronimo-activemq-ra-3.0-SNAPSHOT,ResourceAdapter=geronimo-activemq-ra-3.0-SNAPSHOT,ResourceAdapterModule=org.apache.geronimo.configs/activemq-ra/3.0-SNAPSHOT/car,j2eeType=JCAConnectionManager,name=DefaultActiveMQConnectionFactory
      2011-06-01 16:27:05,894 ERROR [MCFConnectionInterceptor] Error occurred creating
      ManagedConnection for handle: nullManagedConnectionInfo:
      org.apache.geronimo.connector.outbound.ManagedConnectionInfo@287dba. mc: null]
      javax.resource.ResourceException: Could not create connection.
      ...
      Caused by: javax.jms.JMSException: Could not connect to broker URL:
      tcp://localhost:61716. Reason: java.net.ConnectException: Connection refused
      ...
      -

      In this tested scenario, ActiveMQ is binding to port 61616, even though the PortOffset value is 100.

        Attachments

        1. GERONIMO-5987-new.patch
          7 kB
          Rex Wang
        2. GERONIMO-5987-detail.patch
          6 kB
          Rex Wang
        3. GERONIMO-5987.patch
          2 kB
          Rex Wang

          Issue Links

            Activity

              People

              • Assignee:
                rwonly Rex Wang
                Reporter:
                rglaue Russell E Glaue
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: