3 Replies Latest reply on Apr 17, 2012 9:27 AM by garytully

    JDBC Master/Slave configuration

    Denise Gant Newbie

      The documentation explicitly states that "the slaves keep attempting to grab the lock on the database table, but they do not succeed as long as the master is running. The slaves do not start up any transport connectors or network connectors and are thus inaccessible to messaging clients and brokers."  However, clients get successful connection responses, although not really connected.  I need a way to verify that the slave is not available for connection by a client.  I'm specifically using the stomp protocol to connect.  Any ideas/suggestions?


        • 1. Re: JDBC Master/Slave configuration
          garytully Novice

          In the brokerService main line, the persistence adapter is started before the transport connectors. In the case of JDBC master/slave, the jdbc persistence adapter will block pending lock acquisition, so the transport connectors won't yet be started.


          Are you programatically starting the broker by any chance?


          You should be able to use netstat -a to validate that the stomp listener is not started by the slave broker.

          A telnet to the brokers stomp port should fail with connection refused.


          What stomp client are you using?

          • 2. Re: JDBC Master/Slave configuration
            Denise Gant Newbie

            I looked at the activemq.xml file in the conf directory.  I see where they have import resource=activemq-jdbc.xml at the end outside of the broker node and thus after the transportConnectors node.  Do I need to ask them to not use the import resource= approach to specifying the persistenceAdapter and have them explicitly add the persistenceAdapter within the broker node in the activemq.xml file and above the transportConnectors?

            • 3. Re: JDBC Master/Slave configuration
              garytully Novice

              That could well be the problem. If the import is of the vanilla activemq-jdbc.xml from the sample configuration directory it could lead to two brokers being configured.


              The jdbcPersistenceAdapter must be included in the broker node, and there should only be one  specified for a broker. Typically one replaces the default kahaDB persistence adapter entry with a JDBC persistence adapter.

              Have a peek at the documentation for examples: http://fusesource.com/docs/esb/4.3/amq_persistence/FuseMBPersistJDBCBasics.html