/dev/websphere

5.x JMX, Jython simple script to set trace at the cluster level.

I don't know about you, but I generally get tired pretty quick of turning trace on and off for a cluster. I'll show how to write a script to make this easier.

This script shows how to enable trace for all members of a cluster either just transiently on the current running servers or persistently for the next time the cluster restarts. I use jython mainly because I can't read jacl at all, I find jython much easier to write.
The script talks to the deployment manager so it must be running for this script to operate.

Here is the jython script to execute:
Clustertrace jython

Here is a windows script to make using it easier:
Clustertrace windows script

To use it, ensure the DM is running and run the script on the DM machine. You may need to tweak the cmd file to specify the host for the DM. For now, you need to run the script on the dm node. Just specify the command line args to wsadmin to connect to the right server otherwise.

clustertrace (perm|temp) traceString [--c clustername | --s servername]

perm means makes the changes permanently. They won't take effect until the impacted server(s) are restarted. temp means make the change right now on the running server(s) but if they are restarted then they revert to the permanent trace setting which can be changed with the perm option.

The c option allows a cluster name to be specified and all cluster members will receive the trace string. If you're using temp then only the running cluster members receive the string.

The s option allows a specific server to be set rather than a whole cluster. So, to turn on trace for a cluster use:

clustertrace perm com.ibm.ws.*=all=enabled --c billyCluster

To turn off trace use:

clustertrace perm com.ibm.ws.*=all=disabled --c billyCluster

Change perm to temp to have the change take effect immediately on any running cluster members.

WebSphere 5.0: Making new DataSources or WorkManagers available to a running app without a restart

Some customers want to use JMX to make a DataSource or WorkManager and then without restarting the JVM, look these new objects up in JNDI. This does work normally. Such changes are typically only 'detectd' when the JVM restarts or when a new application is deployed to a running JVM.

You can trigger this rebinding at any time using JMX.

wsadmin> set dsh [$AdminControl queryNames type=DataSourceCfgHelper,process=server1]
wsadmin> $AdminControl invoke $dsh reload

The above snippet will cause server1 to reload the JNDI bindings. Now, you may still see some latency. You can make the DataSource etc on the DM but remember that until those changes are replicated to the node with server1 the above call will do nothing. Replication normally happens quickly and there are wsadmin commands to force a sync now but I don't have them handy. But, once the changes make their way to the server, this JMX call will allow you to access those resources without a restart.

Creating a WorkManager using wsadmin/jmx

Had a customer question today on how to do this so here it is:

puts "Locating WorkManagerProvider"
set wmp [lindex [$AdminConfig list WorkManagerProvider] 0]

puts "Create a new WorkManager"
set attrs {{category "ABFVT"} {description "AsynchBeans FVT WorkManager"} {isGrowable false} {jndiName wm/ABFVT1} {maxThreads 30} {minThreads 20} {name ABFVT_WM1} {numAlarmThreads 10} {serviceNames security;UserWorkArea;com.ibm.ws.i18n;AppProfileService} {threadPriority 5}}
$AdminConfig create WorkManagerInfo $wmp $attrs

puts "Saving Config"
$AdminConfig save

Basically, find the WorkManagerProvider first, then make a list for the attributes and then create the WorkManager and then make sure to do a '$AdminConfig save' to make it permanent.

Using JMX to update threadpools without a restart

There is an MBean available for each WorkManager in a JVM. There is actually an MBean for each thread pool in a JVM. This MBean allows an administrator using wsadmin to tune the size of a WorkManager at runtime without restarting the server. These changes are purely transient and will be lost if the server is restarted. The admin object for the WorkManager should be modified if the changes are to be permanent.

Enumerating the ThreadPool MBeans on a server.

Execute the wsadmin command and attach to a single server.
The type of the MBean is ThreadPool. The following command shows all the ThreadPools running in a server:

wsadmin>$AdminControl queryNames type=ThreadPool,*

WebSphere:platform=common,cell=bnewportxp,version=5.0,
name=WorkManager:BPESchedulerWorkManager,
mbeanIdentifier=WorkManager:BPESchedulerWorkManager,
type=ThreadPool,node=bnewportxp,process=server1
…
wsadmin>

The thread pools corresponding to a WorkManager are named using the WorkManager:name convention which should allow you to locate the WorkManager that you are interested in tuning. The name is the name attribute specified when the WorkManager is defined. Let us say we want to get the maximum number of threads allowed for this WorkManager.

Obtaining a reference on a particular WorkManager

wsadmin>set wm [$AdminControl completeObjectName WebSphere:type=ThreadPool,mbean
Identifier=WorkManager:BPESchedulerWorkManager,*]
wsadmin>

First, we need to assign the MBean to a variable. The above command stores a reference to the WorkManager’s MBean to wm. Now, we can invoke operations on this instance. You can determine the operations permissible using the following command.

wsadmin>$Help operations $wm
Operation
java.lang.String getName()
int getMaximumPoolSize()
void setMaximumPoolSize(int)
int getMinimumPoolSize()
void setMinimumPoolSize(int)
long getKeepAliveTime()
void setKeepAliveTime(long)
boolean isGrowAsNeeded()
void setGrowAsNeeded(boolean)
com.ibm.websphere.management.statistics.Stats getStats()
wsadmin>

We can see the permissible operations above. We can inquire what the current maximum number of threads in the WorkManager using the following command:

wsadmin>$AdminControl invoke $wm getMaximumPoolSize
5
wsadmin<

Changing the maximum thread pool size.
Here, we saw it currently has a maximum of 5 threads. Let’s say we want it to be 10. The following command will do this.

wsadmin>$AdminControl invoke $wm setMaximumPoolSize 10
wsadmin>$AdminControl invoke $wm getMaximumPoolSize
10
wsadmin>

Here, the setMaximumPoolSize changes the number of threads to 10 and we verified this by running the getMaximumPoolSize method and it now returns 10 rather than 5. This is purely transient and takes effect immediately. If you want it to be permanent then use the $AdminConfig object to do this. Any changes made using $AdminConfig are not immediate. Normally, a restart is necessary for the change to take effect. The $AdminControl approach allows such a change to occur immediately without a restart but unless backed by $AdminConfig then this change will be purely transient and the permanent value is restored on a restart.

Summary
This approach can be used to tune any ThreadPool object at runtime including the ones for the ORB, MDB listener ports, and servlet containers.