IBM Support

PH01591: NONPERSISTENT EJB TIMER DYING IF TIMEOUT THROWS EXCEPTION ON LAST RETRY

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

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



Document information

More support for: WebSphere Application Server
General

Software version: 900

Reference #: PH01591

Modified date: 25 March 2019