Configuring the timer service using scripting
Use wsadmin scripting to configure the Enterprise JavaBeans (EJB) timer service.
Before you begin
About this task
The EJBTimer configuration object exists at the server level. This means that each server in a multi-server environment has its own EJBTimer configuration object and must be configured individually.
Procedure
- Launch the scripting tool using the Jython or scripting language.
- Determine the attributes on the EJBTimer configuration
object that must be updated. You can update the following attributes on the EJBTimer configuration object:
- datasourceJNDIName
- datasourceAlias
- tablePrefix
- pollInterval
- numAlarmThreads
- schedulerJNDIName
- numNPTimerThreads
- nonPersistentTimerRetryCount
- nonPersistentTimerRetryInterval
- uniqueTimerManagerForNP
For a complete description of each attribute, see information about EJB timer service settings.
Four types of EJB timers exist:- Persistent timers, supported by a default internal scheduler instance.
- Persistent timers, supported by a custom scheduler instance.
- Non-persistent timers, sharing a thread pool with persistent timers.
- Non-persistent timers, not sharing a thread pool with persistent timers.
The EJBTimer configuration object contains the configuration data for all four types of EJB timers. Each of the four types of timer uses a subset of the configuration attributes on the EJBTimer configuration object. All the attributes on the EJBTimer configuration object are used to configure at least one of the timer types, and none of the attributes are used to configure all the timer types. Thus, you must understand which type of timer you are configured to use, and which configuration attributes apply to that type of timer.
Table 1. Timer types and configuration attributes . Indicates the EJBTimer attributes that are used to configure each type of timer. Attribute Persistent, default scheduler Persistent, custom scheduler Non-persistent, shared thread pool Non-persistent, unique thread pool datasourceJNDIName Yes No, specified on custom scheduler configuration instead No No datasourceAlias Yes No, specified on custom scheduler configuration instead No No tablePrefix Yes No, specified on custom scheduler configuration instead No No pollInterval Yes No, specified on custom scheduler configuration instead No No numAlarmThreads Yes No Yes No schedulerJNDIName No Yes No No numNPTimerThreads No No No Yes nonPersistentTimerRetryCount No No Yes Yes nonPersistentTimerRetryInterval No No Yes Yes uniqueTimerManagerForNP No No Yes Yes The presence of a value for the schedulerJNDIName attribute determines which type of persistent timer is used. If the schedulerJNDIName attribute has a value, then a custom scheduler instance is used. If the schedulerJNDIName does not have a value, then the default internal scheduler instance is used.
The numAlarmThreads attribute maps to the Number of timer threads option in the Persistent EJB timer configuration section of the administrative console. The numNPTimerThreads attribute maps to the Number of timer threads option in the Non-persistent EJB timer configuration section of the administrative console.
The uniqueTimerManagerForNP attribute maps to the Share thread pool configured for persistent timers and Create a separate thread pool for non-persistent timers options in the administrative console.
The uniqueTimerManagerForNP attribute determines if the thread pool is shared between persistent and non-persistent timers. It also determines if the numAlarmThreads or numNPTimerThreads configuration attribute is used.
Table 2. The uniqueTimerManagerForNP attribute impacts . The uniqueTimerManagerForNP attribute affects both thread pool sharing and thread configuration. uniqueTimerManagerForNP attribute Persistent and non-persistent timers share a thread pool Thread configuration attribute that is used Thread configuration attribute that is ignored true No numNPTimerThreads numAlarmThreads false Yes numAlarmThreads numNPTimerThreads - Obtain a reference to the correct EJBTimer configuration
object and store it in a variable.
Using Jacl:
set timer [$AdminConfig list EJBTimer]
Using Jython:timer = AdminConfig.list('EJBTimer')
If you have a multi-server environment, then multiple EJBTimer configuration objects are returned. Programmatically loop over the list and select the EJBTimer configuration object that corresponds to the server you must update.
In a multi-server environment, as an alternative to programmatically looping over the list of EJBTimer objects, you can manually select the correct EJBTimer object and copy and paste it into your variable.
For example, if the output of your
AdminConfig list
command is:(cells/myCell01/nodes/myCellManager01/servers/dmgr|server.xml#EJBTimer_1)(cells/myCell01/nodes/myNode02/servers/server1|server.xml#EJBTimer_1246050925244)
Copy and paste the reference for the needed EJBTimer object into your variable.
Using Jacl:set timer "(cells/myCell01/nodes/myNode02/servers/server1|server.xml#EJBTimer_1246050925244)"
Using Jython:timer = "(cells/myCell01/nodes/myNode02/servers/server1|server.xml#EJBTimer_1246050925244)"
- Update attributes on the EJBTimer configuration object.
Update attributes on the EJBTimer configuration object using the
AdminConfig modify
command. The first argument to the command is the EJBTimer reference that you obtained in the previous step. The second argument to the command is a list of name-value pairs.To set a retry count of 10 attempts, and a retry interval of 15 seconds between each attempt:
Using Jacl:set update "{nonPersistentTimerRetryCount 10} {nonPersistentTimerRetryInterval 15}" $AdminConfig modify $timer $update
Using Jython:AdminConfig.modify(timer, '[[nonPersistentTimerRetryCount "10"] [nonPersistentTimerRetryInterval "15"]]')
- Save the configuration changes. Using Jython:
AdminConfig.save()
Using Jacl:$AdminConfig save
- In a network deployment environment only, synchronize the
node.
Using Jacl:
set sync1 [$AdminControl completeObjectName type=NodeSync,node=<your node>,*] $AdminControl invoke $sync1 sync
The node synchronization in these examples must be executed while connected to the server.sync1 = AdminControl.completeObjectName('type=NodeSync,node=<your node>,*') AdminControl.invoke(sync1, 'sync')