Cluster member settings
To manage the members of a cluster. A cluster of appservers are managed together and participate in workload management.
A copy of the first cluster member created is stored as part of the cluster data and becomes the template for all additional cluster members created.
Any individual configuration change that you make to a cluster member does not affect the settings of the cluster member template. Use wsadmin commands to modify the cluster member template, or we can click...
Servers | Clusters | WebSphere application server clusters | cluster_name | Clusters member | Templates
Any change that you make to the template does not affect existing cluster members.
To view this admin console page, click
Servers | Clusters | WebSphere application server clusters | cluster_name
On the Configuration tab, we can edit fields. We can also click Installed applications. to view the status of applications that are running on this server. On the Runtime tab, which only appears when the cluster member is running, we can look at information about this cluster member. However, the information that displays on this page is read-only. You must return to the Configuration tab to change any of the settings that display.
- Member name
-
Name of the appserver in the cluster. On most platforms, the name of the server is the process name. The member name must match the name of one of the servers that are listed on the appservers page.
- Node name
-
Name of the node on which the cluster member is running.
- Weight
-
Controls the number of requests that are directed to the appserver. Even though you specify a value of 0 to 20 as the weight of a server, the weight assigned to the server is a proportion, in which, the weight assigned to the server is the numerator, and the sum of the weights of all members of the cluster is the denominator.
When you add a new member to a cluster, the number of client, or application requests that are sent to each server in the cluster decreases, assuming the number of requests coming into the cluster stays the same. Similarly when you remove a new member from a cluster, the number of client or application requests that are sent to each server in the cluster increases, assuming the number of requests coming into the cluster stays the same.
For example, if we have a cluster that consists of members A, B, and C with weights 2, 3, and 4, respectively, then 2/9 of the requests are assigned to member A, 3/9 are assigned to member B, and 4/9 are assigned to member C. If a new member, member D, is added to the cluster and member D has a weight of 5, then member A now gets 2/14 of the requests, member B gets 3/14 of the requests, member C gets 4/14 of the requests, and member D gets 5/14 of the requests.
Data type Integer Range 0 to 20 - Unique ID
-
Numerical identifier for the appserver that is unique within the cluster. The ID is used for affinity.
Data type Integer - Run in development mode
-
Enable this option may reduce the startup time of an appserver. This might include Java ™ virtual machine (JVM) settings, such as disabling bytecode verification and reducing Just in Time (JIT) compiler compilation costs. Do not enable this setting on production servers. This setting is only available on appservers that are running in V6.0 and or higher cells.
Specifies to use the JVM settings, -Xverify and -Xquickstart, on startup. After selecting this option, save the configuration and restart the server to activate development mode.
The default setting for this option is false, which indicates that the server is not started in development mode. Setting this option to true specifies that the server is started in development mode, using settings that decrease server startup time.
Data type Boolean Default false - Parallel start
-
Whether to start the server on multiple threads. When you start the server on multiple threads, the server components, services, and applications start in parallel rather than sequentially, which might shorten the startup time.
The default setting for this option is true, which indicates that the server uses multiple threads when it starts. Setting this option to false specifies that the server uses a single thread when it starts, which might lengthen startup time.
The order in which applications start depends on the weight you assign to each application. The application with the lowest starting weight starts first. Applications with the same starting weight start in parallel. Use the Starting weight field on...
Applications | Application Types | WebSphere enterprise applications | application_name | Startup behavior
Data type Boolean Default true - Start components as needed
-
Select this field if we want the cluster member components started as they are needed by an application that is running on this cluster member.
When this property is selected, cluster member components are dynamically started as they are needed. When this property is not selected, all of the cluster member components are started during the cluster startup process. Therefore, selecting this option can improve startup time, and reduce the memory footprint of the cluster members, because fewer components are started during the startup process.
Starting components as they are needed is most effective if all of the applications, that are deployed on the cluster, are of the same type. For example, using this option works better if all of the applications are Web apps that use servlets, and JSPs. This option works less effectively if the applications use servlets, JSPs and EJB.
To ensure compatibility with other WebSphere products, the default setting for this option is deselected. Before selecting this option, verify that any other WebSphere products, that we are running in conjunction with this product, support this functionality.
- Access to internal server classes
-
Whether the applications that are running on this server can access many of the server implementation classes.
If we select Allow, then, applications can access most of the server implementation classes. If we select Restrict, then applications cannot access server implementation classes. The applications get a ClassNotFoundException error if they attempt to access these classes.
Usually, you should select Restrict for this property, because most applications use the supported APIs, and do not need to access any of the internal classes. However, if the application requires the use of one or more of the internal server classes, then select Allow as the value for this property.
The default value for this property is Allow.
- Class loader policy
-
Whether there is a single class loader that loads all of the applications, or a different class loader loads each application.
- Class loading mode
-
Whether the class loader searches in the parent class loader, or in the application class loader first to load a class. The standard for Developer Kit class loaders and product class loaders is Classes loaded with parent class loader first.
This field only applies if we set the Class loader policy field to Single.
If we select Classes loaded with local class loader first (parent last), the application can override classes that are contained in the parent class loader, but this action can potentially result in ClassCastException, or linkage errors, if we have mixed use of overridden classes and non-overridden classes.
- Process ID
-
Native operating system process ID for this server.
The process ID property is read only. The system automatically generates the value.
- Cell name
-
Name of the cell in which this server is running.
The Cell name property is read only.
- Node name
-
Name of the node in which this server is running.
The Node name property is read only.
- State
-
Runtime state for this server.
The State property is read only.
Related concepts
Clusters and workload management
Related tasks
Add members to a cluster
Set application startup
Modify cluster member templates using scripting
Related
Cluster member collection