WildFly Domain Mode Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(56 intermediate revisions by the same user not shown)
Line 6: Line 6:
=Managed Domain=
=Managed Domain=


A JBoss ''managed domain'' is a centrally-managed group of JBoss instances running on multiple physical hosts. The domain provided centralized management of modules, extensions, system properties, deployments, profiles and deployments. Managed domain is one of the two operating modes a JBoss EAP instance is capable of - the other is ''standalone''. While running in managed domain mode, multiple JBoss EAP instance are managed from a central location, the domain controller, and share a [[#Management_Policy|common management policy]]. A domain has one or more domain controllers, one or more host controllers and zero or more server groups. A server group can span multiple hosts.
<span id='Domain_Mode'></span>A JBoss ''managed domain'' is a centrally-managed group of JBoss instances running on multiple physical hosts. The domain provided centralized management of modules, extensions, [[WildFly_System_Properties#Top_Level|system properties]], deployments, profiles and deployments. Managed domain is one of the two operating modes a JBoss EAP instance is capable of - the other is ''standalone''. While running in managed domain mode, multiple JBoss EAP instance are managed from a central location, the domain controller, and share a [[#Management_Policy|common management policy]]. A domain has one or more domain controllers, one or more host controllers and zero or more server groups. A server group can span multiple hosts.


[[Image:EAPDomain.png]]
[[Image:EAPDomain.png]]
==Domain Topology==
The topology of a JBoss domain is displayed by the domain console http://controller-host:9990/. Go to Runtime -> Toplogy.
==Domain Configuration==
{{Internal|WildFly Domain Mode Configuration|Domain Mode Configuration}}


=Management Policy=
=Management Policy=


The central management policy for a domain in stored in [[domain.xml|$JBOSS_HOME/domain/configuration/domain.xml]]. The hosts and the server instances that are part of the domain are not specified in domain.xml, directly. The management policy list a series of [[#Profile|profiles]], and a series of [[#Server_Group|server groups]]. Each server group refers a profile, jvm parameters and a [[#Socket_Binding_Group|socket binding group]]. The association between actual [[#Server_Instance|server instances]], running on different hosts, and the server group, is made on the[[#Host|hosts]] running those instances, in [[host.xml|$JBOSS_HOME/domain/configuration/host.xml]].
The central management policy for a domain in stored in [[domain.xml|$JBOSS_HOME/domain/configuration/domain.xml]]. The hosts and the server instances that are part of the domain are not specified in domain.xml, directly. The management policy list a series of [[WildFly_Concepts#Profile|profiles]], and a series of [[#Server_Group|server groups]]. Each server group refers a profile, jvm parameters and a [[WildFly_Networking_Concepts#Socket_Binding_Group|socket binding group]]. The association between actual [[#Server_Instance|server instances]], running on different hosts, and the server group, is made on the[[#Host|hosts]] running those instances, in [[host.xml|$JBOSS_HOME/domain/configuration/host.xml]].


{{Warn|domain.xml contains configuration, not topology. This approach allows to add instances to a server group without modifying domain.xml.}}
{{Warn|domain.xml contains configuration, not topology. This approach allows to add instances to a server group without modifying domain.xml.}}
Line 18: Line 26:
=Domain Controller=
=Domain Controller=


The ''domain controller'' is the Java process from which the domain is controlled. The domain controller ensures that each server instance is configured according to the [[#Management_Policy|management policy]] of the domain. The domain controller's responsibilities are to maintain the domain's central management policy, to ensure all [[#Host_Controller|host controllers]] are aware of its current contents and to assist the host controllers in ensuring that all running [[#Server_Instance|server instances]] are configured in accordance with this policy. For the host it runs on, the domain controller takes also on the [[#Host_Controller|host controller]] responsibilities, controlling the server instances collocated on the host. For more details about the relationship between domain and host controllers, see the "[[#Relationship_Between_a_Host_Controller_and_a_Domain_Controller|Relationship between a Host Controller and a Domain Controller]]" section. The domain controller must be started before any servers in any server groups in the domain. The domain controller process is started with $JBOSS_HOME/bin/domain.sh script.  
The ''domain controller'' is the Java process from which the domain is controlled. The domain controller ensures that each server instance is configured according to the [[#Management_Policy|management policy]] of the domain. The domain controller's responsibilities are to maintain the domain's central management policy, to ensure all [[#Host_Controller|host controllers]] are aware of its current contents and to assist the host controllers in ensuring that all running [[#Server_Instance|server instances]] are configured in accordance with this policy. For the host it runs on, the domain controller takes also on the [[#Host_Controller|host controller]] responsibilities, controlling the server instances collocated on the host. For more details about the relationship between domain and host controllers, see the "[[#Relationship_Between_a_Host_Controller_and_a_Domain_Controller|Relationship between a Host Controller and a Domain Controller]]" section. The domain controller must be started before any servers in any server groups in the domain.  


==Domain Controller High Availability==
Some special precautions must be taken during the installation of the domain controller, they are described here [[WildFly Domain Controller Post-Install Configuration|Domain Controller Post-Install Configuration]]. Once installed, the domain controller process is started with $JBOSS_HOME/bin/domain.sh script.
 
==High-Availability Domain Controller==


Since EAP 6.3, the domain controllers can be run in a highly available mode:
Since EAP 6.3, the domain controllers can be run in a highly available mode:


{{Internal|WildFly Domain Controller High Availability|Domain Controller High Availability}}
{{Internal|WildFly High Availability Domain Controller|High-Availability Domain Controller}}


=Host Controller=
=Host Controller=
Line 30: Line 40:
The ''host controller'' is a Java process tied to a specific physical or virtual host. The host controller controls the lifecycle of the [[#Server_Instance|application server instances]] running on its [[#Host|host]] by starting and stopping them and assisting the [[#Domain_Controller|domain controller]] in managing them. Each host can run multiple [[#Server_Group|server groups]]. Host controllers delegate domain management tasks to the domain controller. Each host controller has a name unique within the domain. The default name of the default host controller is "master".
The ''host controller'' is a Java process tied to a specific physical or virtual host. The host controller controls the lifecycle of the [[#Server_Instance|application server instances]] running on its [[#Host|host]] by starting and stopping them and assisting the [[#Domain_Controller|domain controller]] in managing them. Each host can run multiple [[#Server_Group|server groups]]. Host controllers delegate domain management tasks to the domain controller. Each host controller has a name unique within the domain. The default name of the default host controller is "master".


The host controller process is started with $JBOSS_HOME/bin/domain.sh script. The startup script launches a dedicated JVM instance that will execute host controller functionality. The JVM process can be identified in the process table by the "-D[Host Controller]" string.If the host controller process dies unexpectedly for some reason, it is automatically restarted by the [[#Process_Controller|process controller]]. The host controller reads its configuration from [[host.xml|$JBOSS_HOME/domain/configuration/host.xml]].
The host controller process is started with $JBOSS_HOME/bin/domain.sh script. The startup script launches a dedicated JVM instance that will execute host controller functionality. The JVM process can be identified in the process table by the "-D[Host Controller]" string. If the host controller process dies unexpectedly for some reason, it is automatically restarted by the [[#Process_Controller|process controller]]. The host controller reads its configuration from [[host.xml|$JBOSS_HOME/domain/configuration/host.xml]].
 
The configuration values for the management and public interface bind addresses for a specific host are host-dependent, and they are defined in the host controller configuration Note that a host controller and all the server nodes running on the same host share the values for the management and public bind addresses. For more details on how to configure the bind addresses, see: {{Internal|WildFly_System_Properties#jboss.bind.address.management_for_Host_and_Domain_Controller|'jboss.bind.address.management' for host and domain controllers}}
 
==Subordinate Host Controller==
 
{{Internal|Subordinate WildFly Host Controller Post-Install Configuration|Subordinate WildFly Host Controller Post-Install Configuration}}
 
==Host==
 
[[#Server_Instance|Server instances]] run on ''hosts''. Every host running in a managed domain has a [[#Host_Controller|host controller]] executing on it and it must have a unique host name - which is also the name of the host controller.


=Relationship Between a Host Controller and a Domain Controller=
=Relationship Between a Host Controller and a Domain Controller=
Line 58: Line 78:
  </host>
  </host>


A host controller can be configured with multiple options for finding the domain controller, in case the primary domain controller fails. Host controllers iterate through the list of options until one succeeds. For details on how to configure the domain controller failover, see [JBoss7 Domain Configuration#DomainControllerFailover].
A host controller can be configured with multiple options for finding the domain controller, in case the primary domain controller fails. Host controllers iterate through the list of options until one succeeds. For details on how to configure the domain controller failover, see "[[WildFly_High_Availability_Domain_Controller|Domain Controller High Availability]]".
 
=Process Controller=
 
=Profile=
 
=Server Group=
 
=Socket Binding Group=
 
=Host=
 
=Server Instance=
 
=Domain Mode=
 
Details about configuring WildFly in domain mode are available here:
 
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[WildFly Domain Mode Configuration]]
</blockquote>
 
=Domain=
 
<font color=red>Migrate https://home.feodorov.com:9443/wiki/Wiki.jsp?page=JBoss7Domain</font></center>
 
A set of system properties available to the entire domain can be declared as described here: [[WildFly_System_Properties#Top_Level|System Properties at the Top of domain.xml]].
 
=Domain Controller=
 
Also see:
 
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[WildFly Domain Controller Post-Install Configuration]]
</blockquote>
 
 
==High-Availability Domain Controller==
 
<font color=red>Definition.</font>
 
For more details, see:
 
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[WildFly High Availability Domain Controller]]
</blockquote>
 
=Host Controller=
 
==Host Controller Networking==
 
The actual values for the management and public interface bind addresses for a specific host are host-dependent, and they are defined in the host controller configuration Note that a host controller and all the server nodes running on the same host share the values for the management and public bind addresses. Also see [[#Server_Node_Networking|server node networking]].
 
For more details on how to configure the bind addresses, see:
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[WildFly_System_Properties#jboss.bind.address.management_for_Host_and_Domain_Controller|'jboss.bind.address.management' for host and domain controllers]]
</blockquote>
 
==Subordinate Host Controller==
 
Also see:
 
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Subordinate WildFly Host Controller Post-Install Configuration]]
</blockquote>
 
=Domain Controller/Host Controller Communication=


Host controllers connect to the domain controller's [[WildFly_Management_Interfaces#The_Native_API_Endpoint|management interface native API endpoint]] to get domain configuration, so the domain controller management functions have to be externally accessible over the management interface, hence the [[WildFly Management Interfaces|management interface]] has to be visible on the management (internal) network. A [[#Subordinate_Host_Controller|subordinate host controller]] does not have to expose its management interface.
Host controllers connect to the domain controller's [[WildFly_Management_Interfaces#The_Native_API_Endpoint|management interface native API endpoint]] to get domain configuration, so the domain controller management functions have to be externally accessible over the management interface, hence the [[WildFly Management Interfaces|management interface]] has to be visible on the management (internal) network. A [[#Subordinate_Host_Controller|subordinate host controller]] does not have to expose its management interface.
Line 130: Line 84:
=Process Controller=
=Process Controller=


=Server Group=
The process controller executes in its own JVM process instance and manages the O/S level processes associated with [[#Domain_Controller|domain controller]], [[#Host_Controller|host controller]] and [[#Server_Instance|server instances]]. The JVM process can be identified in the process table by the "-D[Process Controller]" string. There is one process controller per physical host.


A ''server group'' is a set of WildFly [[#Server|server nodes]] that share the following:
jboss    9563 ... java -D[Process Controller] -server -Xms32m -Xmx128m ... org.jboss.as.process-controller -jboss-home /usr/local/jboss ...
* a common configuration, described in a domain [[#Profile|profile]]
jboss    9596 .. .java -D[Host Controller] ... org.jboss.as.host-controller ...
* optionally, a common jvm configuration, described by the <jvm> configuration element.
* optionally, a set of system properties available only to servers that belong to the server group. The declaration is described here: [[WildFly_System_Properties#Server_Group|System properties per Server Group]].
* a set of port values, described in a domain [[WildFly_Networking_Concepts#Socket_Binding_Group|socket binding group]]
* a set of deployments.  


<pre>
=Server Group=
<server-group name="server-group-A" profile="some-profile">
    <system-properties>
        <property name="some.system.property" value="some value"/>
    </system-properties>
    <jvm name="default">
        <heap size="6000m" max-size="12000m"/>
        <permgen max-size="2048m"/>
    </jvm>
    <socket-binding-group ref="full-ha-sockets"/>
    <deployments>
        <deployment name="..." runtime-name="..."/>
        ...
    </deployments>
</server-group>
</pre>
 
It can be said that the servers of a server group are configured and managed as one, via the domain controller. Server groups allow to apply common management policies, deploy applications to all servers belonging to the server group. The servers of a server group can be subjected to group-wide management operations: all servers can be started or stopped at the same time, in one operation.


The servers belonging to a server group may run on one or multiple VMs. The association between servers, server groups and the VM they run is described here: [[WildFly_Domain_Mode_Concepts#Relationship_Between_Servers_and_Server_Groups| relationship between servers and server groups]].
A server group is a set of JBoss [[#Server|server nodes]] that share a common configuration, declared in a domain [[WildFly_Concepts#Profile|profile]], a common jvm configuration, described by the <jvm> configuration element, a set of [[WildFly_System_Properties#Server_Group|system properties available only to servers that belong to the server group]], a set of port values, described in a domain [[WildFly_Networking_Concepts#Socket_Binding_Group|socket binding group]] and a set of deployments. In domain mode, each server instance belongs to a server group, even if that server group has just one single instance. The server groups are defined and configured in [[domain.xml]].


The server groups are defined and configured in [[domain.xml]].
<server-group name="server-group-A" profile="some-profile">
    <system-properties>
        <property name="some.system.property" value="some value"/>
    </system-properties>
    <jvm name="default">
          <heap size="6000m" max-size="12000m"/>
          <permgen max-size="2048m"/>
    </jvm>
    <socket-binding-group ref="full-ha-sockets"/>
    <deployments>
        <deployment name="..." runtime-name="..."/>
        ...
    </deployments>
</server-group>


In domain mode, each server instance belongs to a server group, even if that server group has just one single instance.
The servers of a server group are configured and managed as one, via the domain controller. Server groups allow to apply common management policies, deploy applications to all servers belonging to the server group. The servers of a server group can be subjected to group-wide management operations: all servers can be started or stopped at the same time, in one operation. The servers belonging to a server group may run on one or multiple virtual machines or physical servers.


==Server Groups and Rolling Upgrades==
==Server Groups and Rolling Upgrades==
Line 168: Line 114:
Different server groups can also have the same profile and deployments. This can allow for rolling application upgrades where the application is upgraded on one server group and then updated on a second server group, avoiding a complete service outage.
Different server groups can also have the same profile and deployments. This can allow for rolling application upgrades where the application is upgraded on one server group and then updated on a second server group, avoiding a complete service outage.


=Server=
=Server Instance=
 
The association between servers, server groups and the VM they run is described here: [[WildFly_Domain_Mode_Concepts#Relationship_Between_Servers_and_Server_Groups| relationship between servers and server groups]].


==Server Node Networking==
<span id='Server'></span>The application server instances are known as ''members of the domain''. Each application server instance runs within its own JVM instance, identified by the "-D[Server:''<server-name>'']" string in the process table. The host controller for the server must be running when the server starts. Once started, the server instances maintain their "live" data ('data', 'log' and 'tmp') under $JBOSS_HOME/domain/servers/''<server-name>''. The configuration values for the server node network interfaces are host-dependent, so the host controller defines the actual values for the public and management bind addresses, in its configuration. The  host controller and all the server nodes running on the same host share the values for the management and public bind addresses.


The actual values for the server node network interfaces are host-dependent, so the host controller defines the actual values for the public and management bind addresses, in its configuration. The  host controller and all the server nodes running on the same host share the values for the management and public bind addresses. Also see [[#Host_Controller_Networking|host controller networking]].
The JMX bus of a server instance can be [[WildFly_and_JMX#Overview|accessed via its remoting subsystem]].


=Relationship Between Servers and Server Groups=
==Relationship Between Servers and Server Groups==


The association between server instances and the hosts they run is defined by the [[#Host_Controller|host controller]] running on each host: the host controller reads its [[host.xml]] configuration file and instantiates the server nodes defined in its <servers> section, During start-up, the host controller determines what [[#Server_Group|server group]] a specific server instance is part of, and pulls the profile configuration, port definitions and jvm configuration associated with that server group from the domain controller.
The association between server instances and the hosts they run is defined by the [[#Host_Controller|host controller]] running on each host: the host controller reads its [[host.xml]] configuration file and instantiates the server nodes defined in its <servers> section, During start-up, the host controller determines what [[#Server_Group|server group]] a specific server instance is part of, and pulls the profile configuration, port definitions and jvm configuration associated with that server group from the domain controller.


If more than one server instance is required on a specific host, the port offset that allows multiple server instance to run on the same host is specified in the [[host.xml]]'s <server> definition as socket-bindings port-offset. For more details, see [[Host.xml#.3Cservers.3E|host.xml <servers> section]].
If more than one server instance is required on a specific host, the port offset that allows multiple server instance to run on the same host is specified in the [[host.xml]]'s <server> definition as socket-bindings port-offset. For more details, see [[Host.xml#.3Cservers.3E|host.xml <servers> section]].
=Profile=
See:
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[WildFly Concepts#Profile|WildFly Profile]]
</blockquote>


=WildFly Networking Concepts=
=WildFly Networking Concepts=
Line 194: Line 131:


{{Internal|WildFly Networking Concepts|WildFly Networking Concepts}}
{{Internal|WildFly Networking Concepts|WildFly Networking Concepts}}
=JVM Settings in Domain Mode=
{{Internal|WildFly_JVM_Settings#Domain_Mode|JVM Settings in Domain Mode}}

Latest revision as of 21:37, 7 July 2017

Internal

Managed Domain

A JBoss managed domain is a centrally-managed group of JBoss instances running on multiple physical hosts. The domain provided centralized management of modules, extensions, system properties, deployments, profiles and deployments. Managed domain is one of the two operating modes a JBoss EAP instance is capable of - the other is standalone. While running in managed domain mode, multiple JBoss EAP instance are managed from a central location, the domain controller, and share a common management policy. A domain has one or more domain controllers, one or more host controllers and zero or more server groups. A server group can span multiple hosts.

EAPDomain.png

Domain Topology

The topology of a JBoss domain is displayed by the domain console http://controller-host:9990/. Go to Runtime -> Toplogy.

Domain Configuration

Domain Mode Configuration

Management Policy

The central management policy for a domain in stored in $JBOSS_HOME/domain/configuration/domain.xml. The hosts and the server instances that are part of the domain are not specified in domain.xml, directly. The management policy list a series of profiles, and a series of server groups. Each server group refers a profile, jvm parameters and a socket binding group. The association between actual server instances, running on different hosts, and the server group, is made on thehosts running those instances, in $JBOSS_HOME/domain/configuration/host.xml.


domain.xml contains configuration, not topology. This approach allows to add instances to a server group without modifying domain.xml.

Domain Controller

The domain controller is the Java process from which the domain is controlled. The domain controller ensures that each server instance is configured according to the management policy of the domain. The domain controller's responsibilities are to maintain the domain's central management policy, to ensure all host controllers are aware of its current contents and to assist the host controllers in ensuring that all running server instances are configured in accordance with this policy. For the host it runs on, the domain controller takes also on the host controller responsibilities, controlling the server instances collocated on the host. For more details about the relationship between domain and host controllers, see the "Relationship between a Host Controller and a Domain Controller" section. The domain controller must be started before any servers in any server groups in the domain.

Some special precautions must be taken during the installation of the domain controller, they are described here Domain Controller Post-Install Configuration. Once installed, the domain controller process is started with $JBOSS_HOME/bin/domain.sh script.

High-Availability Domain Controller

Since EAP 6.3, the domain controllers can be run in a highly available mode:

High-Availability Domain Controller

Host Controller

The host controller is a Java process tied to a specific physical or virtual host. The host controller controls the lifecycle of the application server instances running on its host by starting and stopping them and assisting the domain controller in managing them. Each host can run multiple server groups. Host controllers delegate domain management tasks to the domain controller. Each host controller has a name unique within the domain. The default name of the default host controller is "master".

The host controller process is started with $JBOSS_HOME/bin/domain.sh script. The startup script launches a dedicated JVM instance that will execute host controller functionality. The JVM process can be identified in the process table by the "-D[Host Controller]" string. If the host controller process dies unexpectedly for some reason, it is automatically restarted by the process controller. The host controller reads its configuration from $JBOSS_HOME/domain/configuration/host.xml.

The configuration values for the management and public interface bind addresses for a specific host are host-dependent, and they are defined in the host controller configuration Note that a host controller and all the server nodes running on the same host share the values for the management and public bind addresses. For more details on how to configure the bind addresses, see:

'jboss.bind.address.management' for host and domain controllers

Subordinate Host Controller

Subordinate WildFly Host Controller Post-Install Configuration

Host

Server instances run on hosts. Every host running in a managed domain has a host controller executing on it and it must have a unique host name - which is also the name of the host controller.

Relationship Between a Host Controller and a Domain Controller

A host controller can interact with only one domain controller - the domain controller that manages the domain the host controllers are part of. The domain controller must be running when the host controllers controlled by it are started.

On the domain controller host, the host controller and the domain controller are executed by the same Java process. This is formally declared in the host.xml configuration file:

<host ...>
    ...
    <domain-controller>
        <local/>
    </domain-controller>
   ...
</host>

Host controllers running on other hosts than the domain controller are explicitly configured to connect to the domain controller:

<host ...>
    ...
    <domain-controller>
        <remote host="${jboss.domain.master.address}" 
                port="${jboss.domain.master.port:9999}" 
                security-realm="ManagementRealm"/>
    </domain-controller>
   ...
</host>

A host controller can be configured with multiple options for finding the domain controller, in case the primary domain controller fails. Host controllers iterate through the list of options until one succeeds. For details on how to configure the domain controller failover, see "Domain Controller High Availability".

Host controllers connect to the domain controller's management interface native API endpoint to get domain configuration, so the domain controller management functions have to be externally accessible over the management interface, hence the management interface has to be visible on the management (internal) network. A subordinate host controller does not have to expose its management interface.

Process Controller

The process controller executes in its own JVM process instance and manages the O/S level processes associated with domain controller, host controller and server instances. The JVM process can be identified in the process table by the "-D[Process Controller]" string. There is one process controller per physical host.

jboss     9563 ... java -D[Process Controller] -server -Xms32m -Xmx128m ... org.jboss.as.process-controller -jboss-home /usr/local/jboss ...
jboss     9596 .. .java -D[Host Controller] ... org.jboss.as.host-controller ...

Server Group

A server group is a set of JBoss server nodes that share a common configuration, declared in a domain profile, a common jvm configuration, described by the <jvm> configuration element, a set of system properties available only to servers that belong to the server group, a set of port values, described in a domain socket binding group and a set of deployments. In domain mode, each server instance belongs to a server group, even if that server group has just one single instance. The server groups are defined and configured in domain.xml.

<server-group name="server-group-A" profile="some-profile">
    <system-properties>
        <property name="some.system.property" value="some value"/>
    </system-properties>
    <jvm name="default">
         <heap size="6000m" max-size="12000m"/>
         <permgen max-size="2048m"/>
    </jvm>
    <socket-binding-group ref="full-ha-sockets"/>
    <deployments>
        <deployment name="..." runtime-name="..."/>
        ...
    </deployments>
</server-group>

The servers of a server group are configured and managed as one, via the domain controller. Server groups allow to apply common management policies, deploy applications to all servers belonging to the server group. The servers of a server group can be subjected to group-wide management operations: all servers can be started or stopped at the same time, in one operation. The servers belonging to a server group may run on one or multiple virtual machines or physical servers.

Server Groups and Rolling Upgrades

Different server groups can also have the same profile and deployments. This can allow for rolling application upgrades where the application is upgraded on one server group and then updated on a second server group, avoiding a complete service outage.

Server Instance

The application server instances are known as members of the domain. Each application server instance runs within its own JVM instance, identified by the "-D[Server:<server-name>]" string in the process table. The host controller for the server must be running when the server starts. Once started, the server instances maintain their "live" data ('data', 'log' and 'tmp') under $JBOSS_HOME/domain/servers/<server-name>. The configuration values for the server node network interfaces are host-dependent, so the host controller defines the actual values for the public and management bind addresses, in its configuration. The host controller and all the server nodes running on the same host share the values for the management and public bind addresses.

The JMX bus of a server instance can be accessed via its remoting subsystem.

Relationship Between Servers and Server Groups

The association between server instances and the hosts they run is defined by the host controller running on each host: the host controller reads its host.xml configuration file and instantiates the server nodes defined in its <servers> section, During start-up, the host controller determines what server group a specific server instance is part of, and pulls the profile configuration, port definitions and jvm configuration associated with that server group from the domain controller.

If more than one server instance is required on a specific host, the port offset that allows multiple server instance to run on the same host is specified in the host.xml's <server> definition as socket-bindings port-offset. For more details, see host.xml <servers> section.

WildFly Networking Concepts

The networking concepts valid for the standalone mode are also used by the domain mode:

WildFly Networking Concepts

JVM Settings in Domain Mode

JVM Settings in Domain Mode