IV42468: HANG AND HIGH SHARED MEMORY USAGE WHEN QUERYING CONNECTION DATA (DIS CONN)

WebSphere MQ V7.5 Fix Pack 7.5.0.3
Fix Pack 7.1.0.5 for WebSphere MQ V7.1

APAR status

• Closed as program error.

Error description

• The queue manager likely to fail with one or more of the
  following FDCs.
  
  Probe Id :- XY132002
  Component :- xstCreateExtent
  Program Name :- amqzlaa0
  Probe Description :- AMQ6119: An internal WebSphere MQ error
  has occurred (Failed to get memory segment:
  shmget(0x00000000, 268435456) [rc=-1 errno=28] No space
  left on device)
  Comment2 :- No space left on device
  
  MQM Function Stack
  zlaMainThread
  zlaProcessMessage
  zlaProcessSPIRequest
  zlaSPIKernel
  zcpCreateMessage
  xcsAllocateMemBlock
  xstExtendSet
  xstCreateExtent
  xcsFFST
  
  On AIX only:
  
  Probe Id          :- XC267011
  Component         :- xehAsySignalMonitor
  Major Errorcode   :- xecE_W_UNEXPECTED_ASYNC_SIGNAL
  Probe Type        :- MSGAMQ6209
  Probe Severity    :- 3
  Probe Description :- AMQ6209: An unexpected asynchronous signal
  (33 : SIGDANGER) has been received and ignored.
  Arith1            :- 33 (0x21)
  Arith2            :- 10354928 (0x9e00f0)
  Comment1          :- SIGDANGER
  
  All platforms:
  
  "ipcs -a" output likely to show lot of shared memory segments
  allocated from mqm user
  
  This problem might also occur when querying non connection data
  (e.g. queue or channel data) that results in request for a
  bigger shared memory segment.
  

Local fix

Problem summary

• ****************************************************************
  USERS AFFECTED:
  Users using queue managers with lot of connections in a system
  running with 8 or more CPUs will be more affected by this
  problem when comparing with a system running with 4 CPUs and
  same number of connections.
  
  Platforms affected:
  All Distributed (iSeries, all Unix and Windows)
  ****************************************************************
  PROBLEM SUMMARY:
  When allocating shared memory WebSphere MQ 7.1 and 7.5 use a
  resource locking optimization based on the number of
  processors. This optimization caused requests for large amounts
  of memory to fail and then retry until all of system shared
  memory was consumed.
  

Problem conclusion

• The optimization has been modified to ensure that any
  allocation request considers the size of the request before
  using the calculation with the number of processors to ensure
  the allocation request is successful.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v7.1       7.1.0.4
  v7.5       7.5.0.3
  
  The latest available maintenance can be obtained from
  'WebSphere MQ Recommended Fixes'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
  
  If the maintenance level is not yet available information on
  its planned availability can be found in 'WebSphere MQ
  Planned Maintenance Release Dates'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
  ---------------------------------------------------------------
  

Temporary fix

Comments

APAR Information

• 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

  WMQ LIN X86 V7

• Fixed component ID

  5724H7224

Applicable component levels

• R710 PSY

     UP