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?
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.
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?
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 <persistenceAdapter> 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