IBM Support

PM93217: In an edge case where udp send fails due to network issues, UDP ‚ ·Channel hangs.

Fixes are available

PM93217;8.0.0: In an edge case where udp send fails due to network issues, UDP ?
8.0.0.8: WebSphere Application Server V8.0 Fix Pack 8
8.5.5.2: WebSphere Application Server V8.5.5 Fix Pack 2
8.0.0.9: WebSphere Application Server V8.0 Fix Pack 9
8.5.5.3: WebSphere Application Server V8.5.5 Fix Pack 3
8.5.5.4: WebSphere Application Server V8.5.5 Fix Pack 4
8.0.0.10: WebSphere Application Server V8.0 Fix Pack 10
8.5.5.5: WebSphere Application Server V8.5.5 Fix Pack 5
8.5.5.6: WebSphere Application Server V8.5.5 Fix Pack 6
8.0.0.11: WebSphere Application Server V8.0 Fix Pack 11
8.5.5.7: WebSphere Application Server V8.5.5 Fix Pack 7
8.5.5.8: WebSphere Application Server V8.5.5 Fix Pack 8
8.0.0.12: WebSphere Application Server V8.0 Fix Pack 12
8.5.5.9: WebSphere Application Server V8.5.5 Fix Pack 9
8.5.5.10: WebSphere Application Server V8.5.5 Fix Pack 10
8.5.5.11: WebSphere Application Server V8.5.5 Fix Pack 11
8.0.0.13: WebSphere Application Server V8.0 Fix Pack 13
8.5.5.12: WebSphere Application Server V8.5.5 Fix Pack 12
8.0.0.14: WebSphere Application Server V8.0 Fix Pack 14
8.5.5.13: WebSphere Application Server V8.5.5 Fix Pack 13
8.0.0.15: WebSphere Application Server V8.0 Fix Pack 15
8.5.5.14: WebSphere Application Server V8.5.5 Fix Pack 14
8.5.5.15: WebSphere Application Server V8.5.5 Fix Pack 15
8.5.5.14: WebSphere Application Server V8.5.5 Fix Pack 14
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
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

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Customer is running into OutOfMemory condition. On review of
    the heapdump, following code is showing as the leak suspect.
    .
    com.ibm.ws.sip.stack.transaction.transport.connections.channelfr
    .channelframework.SipUdpConnLink$SendThread
    
    If a UDP send fails writing to the network card/interface in
    the UDP Channel, further UDP writes will hang, causing the
    caller (SIP Container in this case) to queue up its writes,
    leading to an OOM.  This is a rare edge case.
    

Local fix

  • N/A
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of IBM WebSphere Application      *
    *                  Server V8.0 and V8.5 using SIP or the UDP   *
    *                  Channel                                     *
    ****************************************************************
    * PROBLEM DESCRIPTION: UDP Channel hangs if UDP Send fails     *
    *                      when send buffer full.                  *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    In a rare edge case, the UDP Channel can hang if a UDP Send
    fails because the OS UDP Send Buffer is full.  When the hang
    occurs, upstream components using the UDP Channel(like SIP
    Container or SIP Proxy) can experience an OOM because their
    responses backup.
    If this occurs in the SIP Container, the heapdump will show
    something similar to:
    "com.ibm.ws.sip.stack.transaction.transport.connections.channelf
    ramework.SipUdpConnLink$SendThread" occupies 1,334,818,488
    (81.00%) bytes. The memory is accumulated in one instance of
    "java.util.LinkedList$Link".
    The problem occurs because after the send fails, it is
    reprocessed to be attempted again.  When the second attempt
    succeeds, the code path handling the asynchronous send
    mis-interprets the result and gets into a state where it
    believes it needs to send something but has nothing to send
    (because it was successful).
    

Problem conclusion

  • This problem was corrected by altering the code that
    reprocesses the send, so that it correctly identifies a
    successful send the 2nd time around.  This prevents the
    looping condition and allows for the correct upstream
    notification of the result.
    
    The fix for this APAR is currently targeted for inclusion in
    fix packs 8.0.0.8 & 8.5.5.2 .  Please refer to the Recommended
    Updates page for delivery information:
    http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM93217

  • Reported component name

    WEBS APP SERV N

  • Reported component ID

    5724H8800

  • Reported release

    800

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-07-17

  • Closed date

    2013-08-27

  • Last modified date

    2013-08-27

  • 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

  • R800 PSY

       UP

  • R850 PSY

       UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
28 April 2022