Fixes are available
18.0.0.2: WebSphere Application Server Liberty 18.0.0.2
18.0.0.3: WebSphere Application Server Liberty 18.0.0.3
18.0.0.4: WebSphere Application Server Liberty 18.0.0.4
19.0.0.1: WebSphere Application Server Liberty 19.0.0.1
19.0.0.2: WebSphere Application Server Liberty 19.0.0.2
19.0.0.3: WebSphere Application Server Liberty 19.0.0.3
19.0.0.4: WebSphere Application Server Liberty 19.0.0.4
19.0.0.5: WebSphere Application Server Liberty 19.0.0.5
19.0.0.6: WebSphere Application Server Liberty 19.0.0.6
19.0.0.7: WebSphere Application Server Liberty 19.0.0.7
19.0.0.8: WebSphere Application Server Liberty 19.0.0.8
19.0.0.9: WebSphere Application Server Liberty 19.0.0.9
19.0.0.10: WebSphere Application Server Liberty 19.0.0.10
19.0.0.11: WebSphere Application Server Liberty 19.0.0.11
19.0.0.12: WebSphere Application Server Liberty 19.0.0.12
20.0.0.1: WebSphere Application Server Liberty 20.0.0.1
20.0.0.2: WebSphere Application Server Liberty 20.0.0.2
20.0.0.3: WebSphere Application Server Liberty 20.0.0.3
20.0.0.4: WebSphere Application Server Liberty 20.0.0.4
20.0.0.5: WebSphere Application Server Liberty 20.0.0.5
20.0.0.6: WebSphere Application Server Liberty 20.0.0.6
20.0.0.7: WebSphere Application Server Liberty 20.0.0.7
20.0.0.8: WebSphere Application Server Liberty 20.0.0.8
20.0.0.9: WebSphere Application Server Liberty 20.0.0.9
20.0.0.10: WebSphere Application Server Liberty 20.0.0.10
20.0.0.11: WebSphere Application Server Liberty 20.0.0.11
20.0.0.12: WebSphere Application Server Liberty 20.0.0.12
21.0.0.3: WebSphere Application Server Liberty 21.0.0.3
21.0.0.4: WebSphere Application Server Liberty 21.0.0.4
21.0.0.5: WebSphere Application Server Liberty 21.0.0.5
21.0.0.6: WebSphere Application Server Liberty 21.0.0.6
21.0.0.7: WebSphere Application Server Liberty 21.0.0.7
21.0.0.8: WebSphere Application Server Liberty 21.0.0.8
21.0.0.9: WebSphere Application Server Liberty 21.0.0.9
21.0.0.1: WebSphere Application Server Liberty 21.0.0.1
21.0.0.2: WebSphere Application Server Liberty 21.0.0.2
21.0.0.10: WebSphere Application Server Liberty 21.0.0.10
21.0.0.11: WebSphere Application Server Liberty 21.0.0.11
21.0.0.12: WebSphere Application Server Liberty 21.0.0.12
22.0.0.1: WebSphere Application Server Liberty 22.0.0.1
22.0.0.2: WebSphere Application Server Liberty 22.0.0.2
22.0.0.3: WebSphere Application Server Liberty 22.0.0.3
22.0.0.4: WebSphere Application Server Liberty 22.0.0.4
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
Modified date:
04 May 2022