Create topic/queue on all nodes of symmetric cluster

[raivil]

Hi,

I have a symmetric hornetq cluster. My Application creates topics dinamically using the jms api (JMSManagementHelper.putOperationInvocation, QueueRequestor, etc).

The only way to have a distributed topic is creating it on each node of the cluster.

I can't find any information on how to create the topic on all nodes at once, if that's possible.

How can I easily create the topic on all nodes?

Client configuration uses spring and HornetQJMSClient.createConnectionFactoryWithHA to get session to servers.

<bean id="jmsConnectionFactoryUserCredential" primary="true" class="org.springframework.jms.connection.UserCredentialsConnectionFactoryAdapter">
   <property name="targetConnectionFactory" ref="hornetConnectionFactory"/>
   <property name="username" value="username"/>
   <property name="password" value="password"/>
  </bean>

<bean id="hornetConnectionFactory" class="org.hornetq.api.jms.HornetQJMSClient" factory-method="createConnectionFactoryWithHA">
        <constructor-arg index="0">
            <util:constant id="CF"  static-field="org.hornetq.api.jms.JMSFactoryType.CF" />  
        </constructor-arg>
        <constructor-arg index="1">
            <bean class="org.hornetq.api.core.TransportConfiguration">
                <constructor-arg value="org.hornetq.core.remoting.impl.netty.NettyConnectorFactory" />
                <constructor-arg>
                    <map key-type="java.lang.String" value-type="java.lang.Object">     
                        <entry key="host" value="127.0.0.1"></entry>
                        <entry key="port" value="5446"></entry>
                    </map>
                </constructor-arg>
            </bean>
        </constructor-arg>
    </bean>

Server configuration is pretty much identical to the symmetric-cluster example.

<broadcast-groups>
      <broadcast-group name="SITDR-broadcast-group">
         <group-address>${udp-address:231.7.7.7}</group-address>
         <group-port>9876</group-port>
         <broadcast-period>100</broadcast-period>
         <connector-ref>netty-connector</connector-ref>
     </broadcast-group>
   </broadcast-groups>
   
   <discovery-groups>
      <discovery-group name="SITDR-discovery-group">
         <group-address>${udp-address:231.7.7.7}</group-address>
         <group-port>9876</group-port>
         <refresh-timeout>10000</refresh-timeout>
      </discovery-group>
   </discovery-groups>
   
   <cluster-connections>
      <cluster-connection name="SITDR-HornetQ-Cluster">
         <address>jms</address>
         <connector-ref>netty-connector</connector-ref>
         <retry-interval>500</retry-interval>
         <use-duplicate-detection>true</use-duplicate-detection>
         <forward-when-no-consumers>false</forward-when-no-consumers>
         <max-hops>1</max-hops>
         <discovery-group-ref discovery-group-name="SITDR-discovery-group"/>
      </cluster-connection>
   </cluster-connections>

JMS Topic Creation:

...
               connection = this.getConnectionFactory().createConnection();


            session = connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);
            connection.start();


            final Queue managementQueue = HornetQJMSClient.createQueue("hornetq.management");
            final QueueRequestor requestor = new QueueRequestor((QueueSession) session, managementQueue);
            final Message message = session.createMessage();


            JMSManagementHelper.putOperationInvocation(message, "jms.server", operation, parameters);
            final Message reply = requestor.request(message);
            success = JMSManagementHelper.hasOperationSucceeded(reply);

[jbertram]

I'm not aware of a way to create a JMS destination on ever node of a cluster.

To be clear, the code to create the destination which you are using is not part of the JMS API.

What's your use-case that requires creating JMS destinations on every node of the cluster dynamically?  Perhaps there is a different, better way to approach the issue.

[raivil]

Justin, you're right.

I used the wrong term. should be "The management via JMS", not JMS Api.

About the use case. Here's the scenario.

Each silo (physical building) have servers with an application/app server, database and a hornetq instance.

The application is able to connect to several external systems (antenas, radios, everything that can be connected to a network). The data from the external system is sent to a topic and can be consumed by many consumers such as front-ends or other processing routines. The application only knows the local hornetq.

We have many silos. Each silo should be able to see data from other silos. So we have to propagate that information to all the other silos. 

No data needs to be persistent. No backup is needed.

Resuming, the data from one external system must be available to all silos. A simple solution would be a single hornetq instance, but the silo can be disconnect  sometimes and it needs to work on it's own.

A symmetric cluster looks like a first solution for us.

I've done some tests and it works ok. If a hornetq instance fails in one silo, another instance can be used transparently.

The only problem is for messages to be propagated through all the silos I need to create the topic on each hornetq instance.

If there is a easy/transparent way of propagating the creation of topic/queue on all instances of a cluster, that would be great.

[jbertram]

I still don't understand where the requirement to dynamically create topics comes in.  Can you elaborate on that point specifically?  What prevents you from configuring the topics statically in the hornetq-jms.xml?

[raivil]

The external systems can be added or deleted at execution time. They can be modified or duplicated to generate new outputs.

If I configure topics in hornetq-jms.xml I'll need to redeploy several times and the buildings aren't really very accessible.

[jbertram]

Couple of ideas...

• Just use a single topic for all messages and use message properties to differentiate the messages and use subscriptions with selectors to consume them.  That would give you maximum flexibility.
• Instead of deploying HornetQ standalone use Wildfly instead.  You can leverage Wildfly's domain mode to manage all the different servers (which includes updating the configuration of all servers with a single command).

[raivil]

Hey Justin,

Thanks for the ideias. It gave my team some starting points to fix the existing problems and find a more suitable solution.

att,