Network Deployment (Distributed operating systems), v8.0 > Reference > Sets
Cluster member settings
Use this page to manage the members of a cluster. A cluster of application servers are managed together and participate in workload management.
A copy of the first cluster member that you create is stored as part of the cluster data and becomes the template for all additional cluster members that you create.
Any individual configuration change that you make to a cluster member does not affect the configuration settings of the cluster member template. We can use wsadmin commands to modify the cluster member template, or you can click...
Servers > Clusters > WebSphere application server clusters > cluster_name > Clusters members > Templates. Any change that you make to the template does not affect existing cluster members. From the console...
Servers > Clusters > WebSphere application server clusters > cluster_name.
On the Configuration tab, you 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, you can look at information about this cluster member. However, the information that displays on this page is read-only. We must return to the Configuration tab to change any of the settings that display.
Name of the application server 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 application servers page.
Name of the node on which the cluster member is running.
Controls the number of requests that are directed to the application server. Even though you specify a value of 0 to 20 as the weight of a server, the weight that is 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
Specifies a numerical identifier for the application server 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 application server. This might include 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 application servers that are running in v6.0 and or higher cells.
Specifies that you want 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
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 Start weight field on the Applications > Application Types > WebSphere enterprise applications > application_name > Startup behavior page of the admin console to set the starting weight for an application.
Data type Boolean Default true
Start components as needed
Select this field if you 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.
Start 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 applications that use servlets, and JSP. 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 you 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 you select Allow, then, applications can access most of the server implementation classes. If you 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 you set the Class loader policy field to Single.
If you 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.
Native operating system process ID for this server.
The process ID property is read only. The system automatically generates the value.
Name of the cell in which this server is running.
The Cell name property is read only.
Name of the node in which this server is running.
The Node name property is read only.
Runtime state for this server.
The State property is read only.
Clusters and workload management
Add members to a cluster
Configure application startup
Modify cluster member templates using wsadmin.sh
Cluster member collection