IBM Support

PI98247: After batch events config change, batchManagerZos hangs waiting for job completion; batch joblog events not published correctly.

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • After batch events config change, batchManagerZos hangs
    waiting for job completion; batch joblog events not
    published correctly.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of IBM WebSphere Application      *
    *                  Server Liberty- Batch                       *
    ****************************************************************
    * PROBLEM DESCRIPTION: After batch events config change,       *
    *                      batchManagerZos hangs waiting for job   *
    *                      completion; batch joblog events not     *
    *                      published correctly.                    *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The problem with the batchManagerZos client can be explained by
    first explaining the more general problem here.
    
    The batch events function, which publishes a series of JMS
    messages upon different batch job lifecycle events, is enabled
    and configured by the "batchJmsEvents" element.
    
    By default, these messages are published to a documented topic
    tree with root of "batch".  However, a different root can be
    chosen, with server config such as:
    
      <batchJmsEvents topicRoot="root" />
    
    One of these events is the writing of a new job log part, and
    the corresponding message is published to topic:
    <root>/jobs/execution/jobLogPart.
    
    The problem here is that the batch job logging component issuing
    this message caches a reference to a batch events component
    activated from a previous configuration.   If the
    "batchJmsEvents" configuration is updated later in the lifecycle
    of the batch job logging component, it will incorrectly continue
    as if the old batch events configuration were in effect.   The
    job log event could be published to the wrong topic root, or not
    published when it should be, or published when it shouldn't be.
    
    Now, back to batchManagerZos, the batchManagerZos client will
    commonly be run with the --wait and --getJobLog to wait for a
    final execution status and the final job log part for the
    associated job.     This is implemented by waiting for the
    corresponding batch events.   So the fact that the final job log
    part may be published to the wrong topic tree, or not published
    at all, can cause the batchManagerZos client to hang, waiting
    for a response which won't come.
    
    In a similar manner, any other user processing built depending
    or waiting for this job log part message to be published could
    be disturbed or broken.
    

Problem conclusion

  • The batch job logging component was fixed to dynamically obtain
    a reference to the publisher component with the latest batch
    events configuration.
    
    One caveat:
    
    This whole discussion shouldn't be read to imply that
    batchManagerZos can begin subscribing to one topic root, and
    then, within the course of waiting for a single job to complete,
    adjust to handle a new topic root or a deactivation.    It just
    means that, over the life of the server, the batch events
    configuration can be changed.
    
    Though it is not disallowed to change batch events configuration
    during the execution of a job, this can be confusing, and is
    definitely not recommended if any other process is waiting or
    otherwise depending on the results, as batchManagerZos is in the
    case when both  --wait and --getJobLog parameters are specified
    on job submission.
    
    The fix for this APAR is currently targeted for inclusion in fix
    pack 18.0.0.2.  Please refer to the Recommended Updates page for
    delivery information:
    http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
    

Temporary fix

  • Make your "batchJmsEvents" configuration problems before
    starting the server, or after starting the server but before
    beginning any use of the batch function.   Another alternative
    would be, for batchManagerZos, to use only --wait (but not --
    wait and --getJobLog), if the job log can be obtained in some
    separate manner.
    

Comments

APAR Information

  • APAR number

    PI98247

  • Reported component name

    LIBERTY PROFILE

  • Reported component ID

    5724J0814

  • Reported release

    CD0

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2018-05-22

  • Closed date

    2018-05-23

  • Last modified date

    2018-05-23

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    LIBERTY PROFILE

  • Fixed component ID

    5724J0814

Applicable component levels

  • RCD0 PSY

       UP



Document information

More support for: WebSphere Application Server

Software version: CD0

Reference #: PI98247

Modified date: 23 May 2018


Translate this page: