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