WAS v8.5 > Administer applications and their environment > Welcome to administering Asynchronous beans > Administer timer and work managers

Configure work managers

A work manager acts as a thread pool for application components that use asynchronous beans. Use the dmgr console to configure work managers.

If you are not familiar with work managers, refer to the Work managers conceptual topic.

The work manager service is always enabled. In previous versions of the product, the work manager service could be disabled using the administration console or configuration service. The work manager service configuration objects are still present in the configuration service, but the enabled attribute is ignored.

We can define multiple work managers for each cell. Each work manager is bound to a unique place in the JNDI namespace.

The work manager service is only supported from within the EJB Container or web container. Looking up and using a configured work manager from a Java EE application client container is not supported.

  1. Start the dmgr console and select...

      Resources | Asynchronous beans | Work managers | Scope | New

  2. Specify the required properties for work manager settings.

    Scope The scope of the configured resource. This value indicates the location for the configuration file.
    Name The display name for the work manager.
    JNDI Name The JNDI name for the work manager. This name is used by asynchronous beans that must look up the work manager. Each work manager must have a unique JNDI name within the cell.
    Number of Alarm Threads Maximum number of threads to use for processing alarms. Applies to a separate thread pool used for running alarms. A single thread is used to monitor pending alarms and dispatch them. An additional pool of threads is used for dispatching the threads. All alarm managers on the asynchronous beans associated with this work manager share this set of threads. A single alarm thread pool exists for each work manager, and all of the asynchronous beans associated with the work manager share this pool of threads.

    The number of alarm threads specified for this property has no impact on the number of threads we specify for the Minimum Number Of Threads and Maximum Number Of Threads properties. The Number of Alarm Threads property only applies to the thread pool for alarm threads. The Minimum Number Of Threads and Maximum Number Of Threads properties only apply to the main thread pool that handles work requests.

    Minimum Number Of Threads Applies to the main thread pool for work submitted to the work manager. The number of threads to be kept in the thread pool, created as needed.
    Maximum Number Of Threads

    For transitioning users: Applies to the main thread pool for work submitted to the work manager. Maximum number of threads to be created in the thread pool. Maximum number of threads can be exceeded temporarily when the Growable check box is selected. These additional threads are discarded when the work on the thread completes.trns

    Thread Priority The priority to assign to all threads in the thread pool.

    Every thread has a priority. Threads with higher priority are run before threads with lower priority. See setPriority method of the java.lang.Thread class.

  3. [Optional] Specify a Description and a Category for the work manager.

  4. [Optional] Select the Service Names (Java EE contexts) on which you want this work manager to be made available.

    Any asynchronous beans that use this work manager then inherit the selected Java EE contexts from the component that creates the bean. The list of selected services also is known as the "sticky" context policy for the work manager. Selecting more services than are required might impede performance.

    Other optional fields include:

    Work timeout Number of milliseconds to wait before a scheduled work object is released. If a value is not specified, then the timeout is disabled.
    Work request queue size Size of the work request queue. The work request queue is a buffer that holds scheduled work objects and can be a value of 1 or greater. The thread pool pulls work from this queue. If we do not specify a value or the value is 0, the queue size is managed automatically. When the queue size is managed automatically, it is computed as the larger of (maximum_number_of_threads) or 20. If this value computes to a zero value, a queue size of 1 is used. Large values can consume significant system resources.
    Work request queue full action Action taken when the thread pool is exhausted, and the work request queue is full. This action starts when you submit non-daemon work to the work manager. If set to FAIL, the work manager API methods creates an exception instead of blocking.

  5. [Optional] Select Custom Properties > New. Other optional fields include:

    Name lateWorkTime
    Value Number of seconds
    Description Specify a description
    Type Select java.lang.String

    The lateWorkTime custom property is the number of seconds beyond which late-starting work must cause an informational message to be logged. The informational message is logged once per work manager. Default is 60 seconds and a value of 0 disables this property.

    Name lateAlarmTime
    Value Number of seconds
    Description Specify a description
    Type Select java.lang.String

    The lateAlarmTime custom property is the number of seconds beyond which a late-firing alarm must cause an informational message to be logged. The informational message is logged once per work manager. Default is 5 seconds and a value of 0 disables this property.

  6. Save your configuration.


Results

The work manager is now configured and ready for access by application components that must manage the start of asynchronous code.


Subtopics


Related concepts:
Work managers
Use asynchronous beans
Configure work manager custom properties using wsadmin


+

Search Tips   |   Advanced Search