ActiveMQ Persistence Adapter - jdbc

Question

I have a network of brokers which works correctly with durable subscribers. They're on "store and forward" with "kahaDB persistence".
I have an available distributed database with its own JDBC Driver.
I want to know if it's worth creating a JDBC Adapter, for the broker to store messages on this shared database to complete this distributed network.
Is it possible? If yes, is it worth it?
My activemq.xml:
<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd">
<!-- Allows us to use system properties as variables in this configuration file -->
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<value>file:${activemq.conf}/credentials.properties</value>
</property>
</bean>
<!-- Allows log searching in hawtio console -->
<bean id="logQuery" class="org.fusesource.insight.log.log4j.Log4jLogQuery"
lazy-init="false" scope="singleton"
init-method="start" destroy-method="stop">
</bean>
<!-- We change the factory finder to instanciate the correct RedCurrant-class which are compatible -->
<bean id="FactoryDefinition" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
<property name="targetClass">
<value>org.apache.activemq.util.FactoryFinder</value>
</property>
<property name="targetMethod">
<value>setObjectFactory</value>
</property>
<property name="arguments">
<list>
<bean id="ObjectFactory" class="io.redcurrant.activemq.util.RedCurrantObjectFactory"/>
</list>
</property>
</bean>
<!--
The <broker> element is used to configure the ActiveMQ broker.
-->
<broker xmlns="http://activemq.apache.org/schema/core" brokerName="RC1" dataDirectory="${activemq.data}" persistent="true">
<destinationPolicy>
<policyMap>
<policyEntries>
<policyEntry topic=">" >
<pendingMessageLimitStrategy>
<constantPendingMessageLimitStrategy limit="1000"/>
</pendingMessageLimitStrategy>
</policyEntry>
</policyEntries>
</policyMap>
</destinationPolicy>
<managementContext>
<managementContext createConnector="false"/>
</managementContext>
<persistenceAdapter>
<kahaDB directory="/DATA/TestNS/RC1/activemq-1"
concurrentStoreAndDispatchTopics="false"
enableJournalDiskSyncs="true"/>
</persistenceAdapter>
<systemUsage>
<systemUsage>
<memoryUsage>
<memoryUsage percentOfJvmHeap="70" />
</memoryUsage>
<storeUsage>
<storeUsage limit="100 gb"/>
</storeUsage>
<tempUsage>
<tempUsage limit="50 gb"/>
</tempUsage>
</systemUsage>
</systemUsage>
<transportConnectors>
<transportConnector name="openwire" uri="tcp://0.0.0.0:30000?maximumConnections=1000&wireFormat.maxFrameSize=104857600" discoveryUri="redcurrant://default:30000"/>
</transportConnectors>
<networkConnectors>
<networkConnector uri="redcurrant://default"/>
</networkConnectors>
<shutdownHooks>
<bean xmlns="http://www.springframework.org/schema/beans" class="org.apache.activemq.hooks.SpringContextHook" />
</shutdownHooks>
</broker>
<import resource="jetty.xml"/>
</beans>
I work on the integration of ActiveMQ on a distributed system named "RedCurrant", so I create a correct DiscoveryAgent and make some changes in a "jar" which I include in the ActiveMQ/lib.
What I really want to do is a network of broker with persistence. I currently use KahaDB to do this, but is it possible for the brokers to share a database to share messages of a topic more quickly. Should I create a JDBC Adapter (SQLite)?

Answer 1

JDBC/database is not the most performant way to persist messages in ActiveMQ.
I don't see the point in using a database anyway, since JDBC is used to share data between a master and a slave, and not between members in a network of brokers (NoB).
If you want short circuit distribution of messages inside a NoB using a database, you really miss the point of NoB. The brokers in the network should be able to independently handle which destinations to propagate and which to handle locally etc.
If you want the messages to propage through the distributed database instead using the brokers as simple connectors, you have some major work in front of you.