Introduction

HornetQ is a high-performance, multi-protocol messaging system that is built for the WildFly application server. By default, a HornetQ instance runs in a non-HA mode, which can be a limiting factor for systems that require high availability (HA). This article aims to provide detailed steps to convert an existing JNDI-based HornetQ service into a highly available service. High availability ensures that your messaging service remains operational, even in case of server failures.

Setting Up the Environment

Before you start configuring HA for HornetQ, you must have the following prerequisites:

1. Clustered Environment: Ensure that you have at least two WildFly application servers running.
2. Network Setup: The servers must be able to communicate with each other.
3. Backup Servers: Prepare secondary servers that will take over the operations if a primary server fails.

Steps to Make HornetQ HA

1. Configuring Shared Storage

For HA, HornetQ requires a shared storage or a replicated setup to ensure data consistency among servers.

• Shared Store Configuration: You can use NFS, SAN, or any shared file system.
• JDBC Store: For database-backed solutions, configure your datasource to enable a shared database.

2. Setup Clustering

• Cluster Configuration: In the standalone-ha.xml file of WildFly, locate the <hornetq-server> element and add cluster connections.

1<cluster-connection name="my-cluster">
2    <connector-ref>in-vm</connector-ref>
3    <retry-interval>500</retry-interval>
4    <call-timeout>30000</call-timeout>
5    <duplicate-detection>true</duplicate-detection>
6    <message-load-balancing>ON_DEMAND</message-load-balancing>
7    <static-connectors>
8        <connector-ref>netty-connector</connector-ref>
9        <connector-ref>in-vm</connector-ref>
10    </static-connectors>
11</cluster-connection>

3. Configuring HA Policy

• Replication Policy: Modify the <ha-policy> tag to enable replication.

<ha-policy>
    <replication synchronous="true" />
</ha-policy>

• Shared Store: Alternatively, use shared-store as HA policy if shared storage is set up.

<ha-policy>
    <shared-store master="true" />
</ha-policy>

4. Define Backup Server

• Backup Servers: Specify which servers will play primary and backup roles.

1<cluster-connection name="my-cluster">
2    <!-- Backup configuration -->
3    <ha-policy>
4        <replication backup="true" master="false" />
5    </ha-policy>
6</cluster-connection>

5. Configuring JNDI

Appropriately configure your JNDI resources to point to the primary and backup servers.

• Initial Context Factory: Point to the appropriate URL of the HA cluster.

Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
env.put(Context.PROVIDER_URL, "http-remoting://localhost:8080,backup01:8080");

6. Testing Your Configuration

After configuration, ensure that your setup works as expected:

• Use jconsole or any JMX client to monitor the status of your servers.
• Restart the primary server and observe whether the backup server takes over seamlessly.

Common Issues and Troubleshooting

• Network Partitioning: In a network partition, ensure your backup can connect to the primary.
• Access Control: Ensure that the correct security settings are enabled for JNDI resources.
• Resource Locks: Shared storage can have issues with locks; configure a timeout or retry logic.

Conclusion

Implementing a high-availability setup for your HornetQ service significantly improves system reliability and uptime. By configuring clustering, shared or replication storage, HA policies, and backup servers, you ensure that your service continues to function even during failures.

Summary Table

Below is a summary table of the configuration changes and settings required:

By following these steps, administrators can transition an existing JNDI HornetQ service to an HA architecture, ensuring minimal downtime and potential failure mitigation.