Fixes are available
9.0.0.11: WebSphere Application Server traditional V9.0 Fix Pack 11
9.0.5.0: WebSphere Application Server traditional Version 9.0.5 Refresh Pack
9.0.5.1: WebSphere Application Server traditional Version 9.0.5 Fix Pack 1
9.0.5.2: WebSphere Application Server traditional Version 9.0.5 Fix Pack 2
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
9.0.5.3: WebSphere Application Server traditional Version 9.0.5 Fix Pack 3
8.5.5.20: WebSphere Application Server V8.5.5.20
8.5.5.18: WebSphere Application Server V8.5.5 Fix Pack 18
8.5.5.19: WebSphere Application Server V8.5.5 Fix Pack 19
8.5.5.16: WebSphere Application Server V8.5.5 Fix Pack 16
8.5.5.21: WebSphere Application Server V8.5.5.21
APAR status
Closed as program error.
Error description
If a non-persistent EJB timer throws an exception on a timeout method that is also the max attempt to retry the timeout (configured with the "nonPersistentMaxRetries" timer service property) the timer will never schedule the next timeout if it is a recurring timer. Instead the timer will become defunct, and continue to exist until cancelled, and never run again. The proposed change is to have the timer schedule the next normal timeout after hitting max retries and continue on to fire when it would have as if it had succeeded, and reset the number of times retried.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of IBM WebSphere Application * * Server with non-persistent EJB timers that * * reach max retries due to timeout failing * **************************************************************** * PROBLEM DESCRIPTION: Non-Persistent EJB Timers will be * * defunct if they * * throw an exception on their last * * timeout retry * **************************************************************** * RECOMMENDATION: * **************************************************************** Non-Persistent EJB Timers with retry their timeout (if configured to do so) if an exception is thrown during the call to the timeout method, however if the timer fails on the last retry attempt the timer will never fire again, but not be cancelled and can still be retrieved with getTimers()
Problem conclusion
Instead of leaving the timer in a defunct state and relying on customer code to delete and recreate the non-persistent timer, EJB Container will now reschedule a non-persistent timer for it's next normal timeout if the timer fails on it's last retry attempt. This will reset the retry attempts for future timeouts. The fix for this APAR is currently targeted for inclusion in fix pack 9.0.0.11 and 8.5.5.16 for WebSphere Application Server and 18.0.0.4 for WebSphere Liberty. Please refer to the Recommended Updates page for delivery information: http://www.ibm.com/support/docview.wss? rs=180&uid=swg27004980
Temporary fix
The customer can delete and recreate the timer
Comments
APAR Information
APAR number
PH01591
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
900
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2018-08-13
Closed date
2019-03-25
Last modified date
2019-03-25
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
WEBS APP SERV N
Fixed component ID
5724H8800
Applicable component levels
R850 PSY
UP
R900 PSY
UP
Document Information
Modified date:
28 April 2022