Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Using Red Hat JBoss Enterprise Application Platform in Microsoft Azure

Red Hat JBoss Enterprise Application Platform 8.0

Instructions for using Red Hat JBoss Enterprise Application Platform on Microsoft Azure, including configuring high availability.

Red Hat Customer Content Services

Abstract

This book is a guide for using Red Hat JBoss Enterprise Application Platform in Microsoft Azure, including high-availability configuration.

Chapter 1. About JBoss EAP on Microsoft Azure
Copy link

JBoss EAP 8.0 can be used with the Microsoft Azure platform, as long as you use it within the specific supported configurations for running JBoss EAP in Azure. If you are configuring a clustered JBoss EAP environment, you must apply the specific configurations necessary to use JBoss EAP clustering features in Azure.

You can choose between two subscription models for deploying JBoss EAP on Azure: bring your own subscription (BYOS) and pay-as-you-go (PAYG).

The following are the differences between the two offerings:

BYOS
If you already have an existing Red Hat subscription, you can use it for deploying JBoss EAP on Azure with the BYOS model. For more information, see About Red Hat Cloud Access.
PAYG
If you do not have an existing Red Hat subscription, you can choose to pay based on the number of computing resources you used by using the PAYG model.

Chapter 3. About Red Hat Cloud Access
Copy link

If you have an existing Red Hat subscription, Red Hat Cloud Access provides support for JBoss EAP on Red Hat certified cloud infrastructure providers, such as Amazon EC2 and Microsoft Azure. Red Hat Cloud Access allows you to cost-effectively move your subscriptions between traditional servers and public cloud-based resources.

You can find more information about Red Hat Cloud Access on the Customer Portal.

This section describes the supported configurations for running JBoss EAP in Microsoft Azure.

The only virtual machine operating systems supported for using JBoss EAP in Microsoft Azure are:

  • Red Hat Enterprise Linux 8
  • Red Hat Enterprise Linux 9
  • Microsoft Windows Server 2019
  • Microsoft Windows Server 2022

The Red Hat Cloud Access program allows you to use a JBoss EAP subscription to install JBoss EAP on your own Azure virtual machine or one of the above On-Demand operating systems from the Microsoft Azure Marketplace. Note that virtual machine operating system subscriptions are separate from a JBoss EAP subscription.

Other than the above operating system restrictions, see the Customer Portal for further information on supported configurations for JBoss EAP, such as supported Java Development Kit (JDK) vendors and versions.

Vertical scaling is supported for all JBoss EAP clustering use cases.

+ The following horizontal scaling use cases are also supported:

  • Distributed HTTP sessions

    • Via hotrod-session-management

    • Via infinispan-session-management

      • Using invalidation-cache and a shared, persistent cache store

  • Distributed @Stateful EJBs

    • Via infinispan-passivation-store

      • Using invalidation-cache and a shared, persistent cache store

  • Distributed EJB timers

    • Using invalidation-cache and a shared, persistent cache store

  • JPA/Hibernate second-level cache

    • Invalidation or local entity/collection/query caching only

  • Public WildFly clustering API

There are some unsupported features when using JBoss EAP in Microsoft Azure.

ActiveMQ Artemis High Availability Using a Shared Store
JBoss EAP messaging high availability using Artemis shared stores is not supported in Microsoft Azure. To configure JBoss EAP messaging high availability in Azure, see the instructions in the Configuration for ActiveMQ Artemis high availability in Microsoft Azure section.
mod_custer Advertising
If you want to use JBoss EAP as an Undertow mod_cluster proxy load balancer, the mod_cluster advertisement functionally is unsupported because of Azure UDP multicast limitations. For more information, see Configuration for load balancing with mod_cluster in Microsoft Azure.
Virtual Machine Scale Set

Transactions in Microsoft Azure Virtual Machine Scale Set (VMSS) is unsupported because the automatic scale down feature does not wait for all transactions to be completed during the scale down process. This could cause data integrity issues. Microsoft Azure VMSS destroys an EAP VM and does not support proper shutdown, which results in the following limitation for EAP clustering:

  • VMSS should be supported for the configurations, in which the server-side state for HA needs to be externalized to a third-party service, such as Red Hat Data Grid. JBoss EAP supports VMSS for HttpSessions externalization, but not for the stateful session bean.
Azure App Service

JTS is not supported in the JBoss EAP Azure App Service offering.

Note

Although JTS is not supported, Jakarta Transactions are supported under the following conditions:

  • The automatic removal of instances is disabled.
  • Instances are not removed manually, for example, by reducing the number of running instances using the Azure dashboard.

Also, transactions over Jakarta Enterprise Beans-remoting are not supported.

Unsupported Azure Autoscale horizontal scaling for JBoss EAP clustering

The following JBoss EAP clustering use cases are not supported when scaling horizontally:

  • Distributed HTTP sessions

    • Infinispan-session-management

      • Using a distributed, replicated, or scattered cache

  • Distributed @Stateful EJBs

    • Via infinispan-passivation-store

      • Using a distributed, replicated, or scattered cache

  • Distributed EJB timers

    • When using a distributed, replicated, or scattered cache
  • Singleton MDBs

  • JPA/Hibernate Second-Level Cache

    • Distributed, replicated, or scattered entity/collection/query caching
  • Singleton deployments
  • Singleton MSC services

  • Public WildFly clustering API:

Create the virtual machines that will host your JBoss EAP instances in your Microsoft Azure environment. The virtual machines must use an Azure size of Standard_A2 or higher.

You can use either the Azure On-Demand premium images to create your virtual machines or create your own virtual machines manually.

Note

JBoss EAP Azure virtual machine images is now available in the marketplace.

Important

If you are configuring JBoss EAP high availability, you must create your virtual machines inside the same virtual network.

Chapter 7. Server installation on Microsoft Azure
Copy link

Important

If you are using a Red Hat Enterprise Linux On-Demand virtual machine from the Microsoft Azure Marketplace, you must install JBoss EAP using the .zip file or installer methods. You must not register a Red Hat Enterprise Linux On-Demand virtual machine to Red Hat Subscription Management, as you will be billed twice for that virtual machine.

Installing JBoss EAP on a virtual machine in a Microsoft Azure environment is no different from a normal JBoss EAP installation. See the Red Hat JBoss Enterprise Application Platform Installation Methods for instructions.

Some JBoss EAP subsystems must be configured to work properly on cloud platforms, such as Amazon EC2 and Microsoft Azure. This is required because a JBoss EAP server is usually bound to a cloud virtual machine’s private IP address, for example: 10.x.x.x, which is only visible from within the cloud platform. For certain subsystems, this address must also be mapped to a server’s public IP address, which is visible from outside the cloud.

When a client makes a web service request using Service.create(wsdlURL, serviceName);, the user connects to the server public IP address, but is subsequently redirected to an address defined in the server configuration files in the webservices subsystem.

By default, this address is ${jboss.bind.address:127.0.0.1}, which means that on a cloud platform, the caller will be redirected to the server’s private IP address and will be unable to resolve the request. The server’s public IP address has to be configured in the wsdl-host element.

Procedure

  • Configure the server’s public IP address in the wsdl-host element. 

    /subsystem=webservices:write-attribute(name=wsdl-host,value=<PUBLIC_IP_ADDRESS>)
    Copy to Clipboard Toggle word wrap

When using messaging on a cloud platform, the connection factory that the client uses must have a connector pointing to the server’s public IP address.

For this reason a new connector and socket binding must be created for JBoss EAP servers running a full profile.

Prerequisites

  • JBoss EAP is running a full profile.

Procedure

  1. Create the referenced http-public socket binding within the socket-binding-group. 

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=http-public:add(host=<PUBLIC_IP_ADDRESS>,port=${jboss.http.port:8080})
    Copy to Clipboard Toggle word wrap

  2. Create the new http-connector element in the messaging subsystem. 

    /subsystem=messaging-activemq/server=default/http-connector=http-public-connector:add(endpoint=http-acceptor,socket-binding=http-public)
    Copy to Clipboard Toggle word wrap

  3. Set the connectors in the connection-factory, which will be used by clients. For example, configuration of RemoteConnectionFactory as the default connection will be: 

    /subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=connectors, value=["http-public-connector"]
    Copy to Clipboard Toggle word wrap

If you are using JBoss EAP HA features with clustered Jakarta Enterprise Beans on a cloud platform, some extra configuration for the remoting subsystem is required to ensure Jakarta Enterprise Beans clients can receive cluster view updates.

Procedure

  • Configure client-mappings for the remoting subsystem socket binding. 

    /socket-binding-group=standard-sockets/socket-binding=http:write-attribute(name=client-mappings,value=[{ "destination-address" => "<PUBLIC_IP_ADDRESS>", "destination-port" => "8080" }])
    Copy to Clipboard Toggle word wrap

This chapter describes the configurations required for JBoss EAP to run in Microsoft Azure.

If you are starting JBoss EAP as a service on Red Hat Enterprise Linux in Microsoft Azure, you must change the configuration of the JBoss EAP service to ensure that it starts after the Azure virtual machine host name has been initialized.

Procedure

  • Update the /etc/systemd/system/multi-user.target.wants/eap8-standalone.service file to add a dependency on waagent.service.

    Replace the following line: 

    After=syslog.target network.target
    Copy to Clipboard Toggle word wrap

    with this line: 

    After=syslog.target network.target waagent.service
Requires=waagent.service
    Copy to Clipboard Toggle word wrap

As a result of mod_cluster advertising not being supported in Azure, if you are configuring a JBoss EAP load balancing environment, you must ensure that all balancers and workers are bound to IP addresses that are accessible on your internal Microsoft Azure virtual network.

Note

Balancers and workers must be bound to the actual internal Azure virtual IP address, for example 172.28.0.2, and not 0.0.0.0.

Additionally, because of the unavailability of mod_cluster advertising, if you are using JBoss EAP as an Undertow mod_cluster proxy load balancer, you must configure each worker node to use a proxy list containing each balancer’s IP address and port, as shown below: 

/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=proxy-one:add(host="BALANCER_IP_ADDRESS", port="BALANCER_PORT")
/subsystem=modcluster/mod-cluster-config=configuration:list-add(name=proxies,value=proxy-one)
Copy to Clipboard Toggle word wrap

JBoss EAP messaging high availability using Artemis shared stores is not supported in Microsoft Azure. To configure JBoss EAP messaging high availability in Azure, you must use a replicated journal with the AZURE_PING JGroups discovery protocol

using a TCP JGroups stack. For more information on using a replicated journal, see Data Replication in Configuring Messaging for JBoss EAP.

After configuring the TCP JGroups stack with AZURE_PING, you must add the JGroups stack to the discovery-group and broadcast-group jgroups-cluster configurations in the messaging-activemq subsystem. For details, see Server Discovery in Configuring Messaging for JBoss EAP.

Clustering for JBoss EAP is supported in Microsoft Azure. Your Microsoft Azure web application must be integrated with a virtual network to enable clustering. When you restart the web application after the integration is complete, your JBoss EAP instance will start up with a clustered configuration.

You can create an app setting called WEBSITE_DISABLE_CLUSTERING to disable clustering. You can assign any value to the app setting.

For more information about migrating JBoss EAP applications to JBoss EAP on Microsoft Azure, see Migrate JBoss EAP applications to JBoss EAP on Azure App Service in the JBoss EAP on Microsoft Azure article.

For more information about clustering, see Clustering in the JBoss EAP on Microsoft Azure article.

Microsoft Azure does not support JGroups discovery protocols that are based on UDP multicast. Although you may use other JGroups discovery protocols (such as a static configuration (TCPPING), a shared database (JDBC_PING), shared file system-based ping (FILE_PING), or TCPGOSSIP), we strongly recommend that you use the shared file discovery protocol specifically developed for Azure: AZURE_PING.

This section describes configuring your JBoss EAP cluster to use the AZURE_PING JGroups discovery protocol. Ensure that you meet the prerequisites when creating your virtual machines.

AZURE_PING uses a common blob container in a Microsoft Azure storage account. If you do not already have a blob container that AZURE_PING can use, create one that your virtual machines can access.

After creating your blob container, you will need the following information to configure AZURE_PING:

  • storage_account_name: the name of the Microsoft Azure storage account that contains your blob container.
  • storage_access_key: the secret access key of the storage account.
  • container: the name of the blob container to use for PING data.
Important

The following instructions configure AZURE_PING using a UDP JGroups stack. If you will be configuring JBoss EAP messaging high availability in Azure, you must configure AZURE_PING in a TCP JGroups stack instead.

To configure JBoss EAP to use AZURE_PING as the JGroups discovery protocol, you can either use a preconfigured example JBoss EAP configuration file, or modify an existing configuration.

JBoss EAP includes example configuration files for configuring clustering of standalone servers in Microsoft Azure. These files are located in EAP_HOME/docs/examples/configs/ and are standalone-azure-ha.xml and standalone-azure-full-ha.xml.

Note

See the JBoss EAP Configuration Guide for an explanation of the differences between the server profiles.

These sample configuration files are preconfigured for using clustering in Microsoft Azure, and all that is needed is to specify the values for your Azure storage account and blob container.

Copy your desired example configuration file to EAP_HOME/standalone/configuration/.

If you are modifying an existing JBoss EAP high availability configuration, the following changes to the jgroups subsystem are required.

Procedure

  1. Launch the management CLI and embed a server to make offline changes to your chosen configuration file. For example: 

    $ EAP_HOME/bin/jboss-cli.sh
[disconnected /] embed-server --server-config=standalone-ha.xml
    Copy to Clipboard Toggle word wrap

  2. By default, JGroups uses the UDP stack. If you were using another stack, change back to using the UDP stack: 

    [standalone@embedded /] /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=udp)
    Copy to Clipboard Toggle word wrap

  3. Execute the following batch of commands to remove the existing UDP stack and insert a new UDP stack configured for Microsoft Azure:

    Important

    The encoding for storage_access_key used in the following command must be Base64. 

    batch
/subsystem=jgroups/stack=udp:remove
/subsystem=jgroups/stack=udp:add()
/subsystem=jgroups/stack=udp/transport=UDP:add(socket-binding=jgroups-udp,properties={ip_mcast=false})
/subsystem=jgroups/stack=udp/protocol=azure.AZURE_PING:add(properties={storage_account_name="${jboss.jgroups.azure_ping.storage_account_name}", storage_access_key="${jboss.jgroups.azure_ping.storage_access_key}", container="${jboss.jgroups.azure_ping.container}"})
/subsystem=jgroups/stack=udp/protocol=MERGE3:add
/subsystem=jgroups/stack=udp/protocol=FD_SOCK2:add(socket-binding=jgroups-udp-fd)
/subsystem=jgroups/stack=udp/protocol=FD_ALL3:add
/subsystem=jgroups/stack=udp/protocol=VERIFY_SUSPECT2:add
/subsystem=jgroups/stack=udp/protocol=pbcast.NAKACK2:add(properties={use_mcast_xmit=false,use_mcast_xmit_req=false})
/subsystem=jgroups/stack=udp/protocol=UNICAST3:add
/subsystem=jgroups/stack=udp/protocol=pbcast.STABLE:add
/subsystem=jgroups/stack=udp/protocol=pbcast.GMS:add
/subsystem=jgroups/stack=udp/protocol=UFC:add
/subsystem=jgroups/stack=udp/protocol=MFC:add
/subsystem=jgroups/stack=udp/protocol=FRAG4:add
run-batch
    Copy to Clipboard Toggle word wrap
    Note

    If you want to store the values of your Microsoft Azure storage account and blob container in your configuration file, replace the system property references in the above configuration with the values from your Azure environment. In the following command, examples for starting JBoss EAP, the system properties are used.

    The stack XML in your configuration file should look like the following: 

    <stack name="udp">
    <transport type="UDP" socket-binding="jgroups-udp"/>
    <protocol type="RED"/>
    <protocol type="azure.AZURE_PING">
        <property name="storage_account_name">${jboss.jgroups.azure_ping.storage_account_name}</property>
        <property name="storage_access_key">${jboss.jgroups.azure_ping.storage_access_key}</property>
        <property name="container">${jboss.jgroups.azure_ping.container}</property>
    </protocol>
    <protocol type="MERGE3"/>
    <socket-protocol type="FD_SOCK2" socket-binding="jgroups-udp-fd"/>
    <protocol type="FD_ALL3"/>
    <protocol type="VERIFY_SUSPECT2"/>
    <protocol type="pbcast.NAKACK2"/>
    <protocol type="UNICAST3"/>
    <protocol type="pbcast.STABLE"/>
    <protocol type="pbcast.GMS"/>
    <protocol type="UFC"/>
    <protocol type="MFC"/>
    <protocol type="FRAG4"/>
</stack>
    Copy to Clipboard Toggle word wrap

  4. Stop the embedded server and exit the management CLI: 

    [standalone@embedded /] stop-embedded-server
[disconnected /] exit
    Copy to Clipboard Toggle word wrap

To start JBoss EAP using high availability in Microsoft Azure, you must:

  • Use a configuration file that has been configured with the AZURE_PING discovery protocol and specify the required values of your Microsoft Azure storage account and blob container.

  • Bind the private interface to the Microsoft Azure internal IP address that is used for clustering traffic. You can do this at startup, as shown below, or as a set configuration shown in the JBoss EAP Configuration Guide.

    Warning

    For security reasons, you must ensure that you do not expose clustering traffic to unintended networks.

    You can do this by restricting the endpoints to your Microsoft Azure virtual network or by creating a dedicated virtual network and dedicated virtual machine NICs for clustering traffic.

Procedure

  • Start your JBoss EAP high availability instance using the following command. If you stored your Microsoft Azure storage account and blob container values in your configuration file, you can omit the -Djboss.jgroups.azure_ping system property definitions. 

    EAP_HOME/bin/standalone.sh -b <IP_ADDRESS> -bprivate <IP_ADDRESS> --server-config=<EAP_CONFIG_FILE>.xml -Djboss.jgroups.azure_ping.storage_account_name=<STORAGE_ACCOUNT_NAME> -Djboss.jgroups.azure_ping.storage_access_key=<STORAGE_ACCESS_KEY> -Djboss.jgroups.azure_ping.container=<CONTAINER_NAME>
    Copy to Clipboard Toggle word wrap

    For example: 

    EAP_HOME/bin/standalone.sh -b 172.28.0.2 -bprivate 172.28.0.2 --server-config=standalone-azure-ha.xml -Djboss.jgroups.azure_ping.storage_account_name=my_storage_account -Djboss.jgroups.azure_ping.storage_access_key=y7+2x7P68pQse9MNh58Bkk5po9OGzeJc+0IRqYcQ9Cr/Sp4xiUFJVlbY+MGXJRNx3syksikwm4tOYlFgjvoCmw== -Djboss.jgroups.azure_ping.container=my_blob_container
    Copy to Clipboard Toggle word wrap
    Note

    As JBoss EAP subsystems only start when needed, you must deploy a distributable application to your JBoss EAP servers to start the high availability JBoss EAP subsystems.

After you start a second JBoss EAP instance in a cluster, you should see logs similar to the following in the console log of the first server in the cluster: 

INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,eap-server-1) ISPN000094: Received new cluster view for channel server: [eap-server-1|1] (2) [eap-server-1, eap-server-2]
Copy to Clipboard Toggle word wrap

If a JBoss EAP cluster that uses AZURE_PING is shut down abnormally, for example, using kill -9 to end the JBoss EAP process, some stale discovery files may be left in your blob container.

These files are usually cleaned up in a graceful cluster shutdown, but if left there from an abnormal shutdown, it may impact startup performance of cluster members attempting to contact nodes that are no longer online.

If this is a problem for you, you can set the following configuration to make the cluster coordinator remove and refresh all discovery files whenever the cluster view changes. 

/subsystem=jgroups/stack=udp/protocol=azure.AZURE_PING/property=remove_all_data_on_view_change:add(value=true)
Copy to Clipboard Toggle word wrap
Note

Alternatively, if cleaning your container on each view change is not ideal, you can reduce the number of join attempts for a node attempting to join a cluster. The default number of join attempts is 10. For example, to set the number of join attempts to 3: 

/subsystem=jgroups/stack=udp/protocol=pbcast.GMS/property=max_join_attempts:add(value=3)
Copy to Clipboard Toggle word wrap

The stale discovery files will still be present, but a node attempting to join a cluster will not spend as much time attempting to contact nodes that are no longer online.





Revised on 2025-05-07 19:22:52 UTC

Legal Notice
Copy link

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top