Configure EJB asynchronous methods

Configure EJB asynchronous methods

Use wsadmin scripting to configure EJB asynchronous methods.
You have working knowledge of Jacl or Jython and wsadmin scripting.
The behavior for EJB asynchronous methods is configured using the EJBAsync configuration object in the server.xml file. If we are using EJB asynchronous methods, then you might must update the EJBAsync configuration object to obtain the best settings for your environment. The EJBAsync configuration object exists at the server level. This means that each server in a multiple-server environment has its own EJBAsync configuration object and must be configured individually.
Launch the wsadmin scripting tool using the Jython scripting language.

Determine the attributes on the EJBAsync configuration object that must be updated. We can update the following attributes on the EJBAsync configuration object:

Attribute Description
maxThreads Maximum number of threads used in the execution of asynchronous EJB methods.
The default value is 5.
workReqQSize Size of the work request queue. The work request queue is a buffer that holds requested asynchronous methods until a thread is available to run them on.
The sum of the maxThreads and the workReqQSize attributes is the total number of allowable in progress method requests.
For example, if the maxThreads is set to 5 threads, and the workReqQSize is set to 50, then the total number of allowable in-progress method requests is 55.
The default value is 0, indicating that the queue size is managed by the runtime environment. The run time currently uses the larger of 20 and maxThreads.
workReqQFullAction Action taken when the thread pool is exhausted, and work request queue is full.
If set to 1, an exception occurs instead of waiting for a thread, or a place in the queue, to become available.
If set to 0, the thread that is requesting the asynchronous method execution waits until a thread, or place in the queue, becomes available.
The default value is 0.
customWorkManagerJNDIName Specifies the JNDI name used to look up the custom defined work manager in the namespace.
The default value is null.
useCustomDefinedWM Whether a custom-defined work manager instance is used, or the default internal work manager instance.
When the useCustomDefinedWM attribute is set to true, this means that a custom work manager instance is used. In this case, the customWorkManagerJNDIName attribute must be set, and all other attributes are ignored.
When the useCustomDefinedWM attribute is set to false, the default, internal work manager instance is used. In this case, the customWorkManagerJNDIName attribute is ignored, and all other attributes are used to help configure the default work manager instance.
The default value is false.
futureTimeout Amount of time, in seconds, that the server-side future object, which is created as a result of running a fire-and-return asynchronous method, is available. The server-side future object is not valid after you call the get() method, and a value is returned to the remote client. To avoid memory leaks, you must call the get() method on the future object, or specify a positive and non-zero future duration value.
A future duration value of zero indicates that the future object never times out.
The default value is 86400, which means that the future object expires and gets cleaned up by the application server after 24 hours and is no longer available.
A org.omg.CORBA.OBJECT_NOT_EXIST exception is thrown when a call to the get() method is made after the future object expires.
Supported configurations: This value is only applicable for clients that call the enterprise bean using a remote business interface; the value is not used for local business interface or no-interface views. When the asynchronous work has completed, the server sets an alarm for the duration specified to the server-side future object. When the alarm is activated, the server releases all the resources associated with the future object, making it unavailable to the client. If the client calls the get() method on the future object before the duration amount of time, the alarm is canceled and all the resources associated with the future object are released.
Supported configurations: This attribute might affect the number of future objects on the server. Use the AsynchFutureObjectCount PMI statistic to determine the count of open FutureObjects on the server, which can help you determine whether applications are accumulating future objects without calling the get() method on those objects. See the topic, Enterprise bean counters, for more information.

Obtain a reference to the correct EJBAsync configuration object and store it in a variable.
Jacl:
set async [$AdminConfig list EJBAsync]

Jython:
async = AdminConfig.list('EJBAsync')

If we have a multiple-server environment, then multiple EJBAsync configuration objects are returned. Programmatically loop over the list and select the EJBAsync configuration object that corresponds to the server you must update.
In a multiple-server environment, as an alternative to programmatically looping over the list of EJBAsync objects, we can manually select the correct EJBAsync object and copy and paste it into the variable.
For example, the output of the AdminConfig list command is:
(cells/myNode04Cell/nodes/myCellManager01/servers/dmgr|server.xml#EJBAsync_1)(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)
We can copy and paste the reference for the needed EJBAsync object into the variable.
Jacl:
set async "(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)"

Using Jython:
async = "(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)"
Update attributes on the EJBAsync configuration object.
Update attributes on the EJBAsync configuration object using the AdminConfig modify command. As input to the command, specify the EJBAsync reference that you obtained in the previous step, and a list of attributeName and attributeValue combinations.
To set a max thread count of 10 threads, a queue size of 15, and a futureTimeout of 3600 seconds:
Jacl:
set update "{maxThreads 10} {workReqQSize 15} {futureTimeout 3600}"
$AdminConfig modify $async $update
                        
Jython:
AdminConfig.modify(async, '[ [maxThreads "10"] [workReqQSize "15"] [futureTimeout "3600"] ]')
Save the configuration changes.
Jython:
AdminConfig.save()

Jacl:
$AdminConfig save
In a Network Deployment environment only, synchronize the node.
Jacl:
set sync1 [$AdminControl completeObjectName type=NodeSync,node=<your node>,*]
$AdminControl invoke $sync1 sync
Jython:
sync1 = AdminControl.completeObjectName('type=NodeSync,node=<your node>,*')
AdminControl.invoke(sync1, 'sync')
We must run the node synchronization in these examples while connected to the server.
Results
As a result of the updates, the EJBAsync configuration object now reflects the attribute values that specified. Restart your server so that the changes are updated on the server.

Related tasks

Configure remote asynchronous EJB method results

EJB asynchronous methods settings
Enterprise bean counters

Attribute	Description
maxThreads	Maximum number of threads used in the execution of asynchronous EJB methods. The default value is 5.
workReqQSize	Size of the work request queue. The work request queue is a buffer that holds requested asynchronous methods until a thread is available to run them on. The sum of the maxThreads and the workReqQSize attributes is the total number of allowable in progress method requests. For example, if the maxThreads is set to 5 threads, and the workReqQSize is set to 50, then the total number of allowable in-progress method requests is 55. The default value is 0, indicating that the queue size is managed by the runtime environment. The run time currently uses the larger of 20 and maxThreads.
workReqQFullAction	Action taken when the thread pool is exhausted, and work request queue is full. If set to 1, an exception occurs instead of waiting for a thread, or a place in the queue, to become available. If set to 0, the thread that is requesting the asynchronous method execution waits until a thread, or place in the queue, becomes available. The default value is 0.
customWorkManagerJNDIName	Specifies the JNDI name used to look up the custom defined work manager in the namespace. The default value is null.
useCustomDefinedWM	Whether a custom-defined work manager instance is used, or the default internal work manager instance. When the useCustomDefinedWM attribute is set to true, this means that a custom work manager instance is used. In this case, the customWorkManagerJNDIName attribute must be set, and all other attributes are ignored. When the useCustomDefinedWM attribute is set to false, the default, internal work manager instance is used. In this case, the customWorkManagerJNDIName attribute is ignored, and all other attributes are used to help configure the default work manager instance. The default value is false.
futureTimeout	Amount of time, in seconds, that the server-side future object, which is created as a result of running a fire-and-return asynchronous method, is available. The server-side future object is not valid after you call the get() method, and a value is returned to the remote client. To avoid memory leaks, you must call the get() method on the future object, or specify a positive and non-zero future duration value. A future duration value of zero indicates that the future object never times out. The default value is 86400, which means that the future object expires and gets cleaned up by the application server after 24 hours and is no longer available. A org.omg.CORBA.OBJECT_NOT_EXIST exception is thrown when a call to the get() method is made after the future object expires. Supported configurations: This value is only applicable for clients that call the enterprise bean using a remote business interface; the value is not used for local business interface or no-interface views. When the asynchronous work has completed, the server sets an alarm for the duration specified to the server-side future object. When the alarm is activated, the server releases all the resources associated with the future object, making it unavailable to the client. If the client calls the get() method on the future object before the duration amount of time, the alarm is canceled and all the resources associated with the future object are released. Supported configurations: This attribute might affect the number of future objects on the server. Use the AsynchFutureObjectCount PMI statistic to determine the count of open FutureObjects on the server, which can help you determine whether applications are accumulating future objects without calling the get() method on those objects. See the topic, Enterprise bean counters, for more information.