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.