Configure EJB asynchronous methods using scripting

WAS v8.5 > Develop applications > Develop EJB applications > Develop session beans > Configure EJB 3.1 session bean methods to be asynchronous
Configure EJB asynchronous methods using scripting

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 server.xml. If we are using EJB asynchronous methods, then you might must update the EJBAsync configuration object to obtain the best settings for the 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:
Attributes on EJBAsync configuration object. This table describes the attributes on the EJBAsync configuration object.

Attribute Description
maxThreads Maximum number of threads used in the execution of asynchronous EJB methods.
Default 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.
Default is 0, indicating 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.
Default is 0.
customWorkManagerJNDIName Specifies the JNDI name used to look up the custom defined work manager in the namespace.
Default 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.
Default is false.
futureTimeout Amount of time, in seconds, 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 the future object never times out.
Default is 86400, which means 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.
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.
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 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 your 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 your variable.
Jacl:
set async "(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)"

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
Results
As a result of your updates, the EJBAsync configuration object now reflects the attribute values that you specified. Restart your server so the changes are updated on the server.

Subtopics

EJB asynchronous methods settings
Use this page to modify settings on the work manager used in support of Enterprise JavaBeans asynchronous methods.
Enterprise bean counters
Use this page as a reference for properties of enterprise bean counters.

Related

Configure remote asynchronous EJB method results

+
Search Tips | Advanced Search

Attribute	Description
maxThreads	Maximum number of threads used in the execution of asynchronous EJB methods. Default 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. Default is 0, indicating 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. Default is 0.
customWorkManagerJNDIName	Specifies the JNDI name used to look up the custom defined work manager in the namespace. Default 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. Default is false.
futureTimeout	Amount of time, in seconds, 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 the future object never times out. Default is 86400, which means 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. 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. 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.