IT14915: MFT reports BFGUL0002W when agent is both the source and destination and enableMemoryAllocationChecking=true

APAR status

• Closed as program error.

Error description

• MQ MFT v8.0 reports there is not enough memory for the transfer
  when the agent is both the source and destination and agent
  property enableMemoryAllocationChecking is set to true.
  Messages BFGTR0067I and BFGUL0002W are reported in the
  output0.log.
  
  Error message in the output0.log
  
  BFGTR0067I: Transfer ID: 414xxxxxxxx entering recovery, after
  a short pause, due to recoverable error: BFGUL0002W: There is
  insufficient memory available for the transfer with transfer
  id 414xxxxxx to run.
  
  This leads to slow transfers and performance problems.
  
  enableMemoryAllocationChecking determines whether the
  agent checks that there is sufficient memory available to run
  the transfer before it is started. The check is made
  on both the source and destination agents. If there is
  insufficient memory available, the transfer is put into
  recovery, which prevents the agent from failing with an
  out-of-memory error.
  
  Trace shows that there is an initial allocation of memory,
  then the agent finds that additional memory is needed for
  the transfer and allocates more memory. When the transfer
  is complete, only the memory allocated by the second
  request is freed. The initial memory allocation is not.
  
  Additional Symptom(s) Search Keyword(s):
  MFT BFGUL0002W enableMemoryAllocationChecking
  

Local fix

Problem summary

• ****************************************************************
  USERS AFFECTED:
  This issue affects users of the MQ V8 Managed File Transfer
  component who have agents that:
  
  - Have been configured with the agent property
  "enableMemoryAllocationChecking" set to the value true
  - And are acting as both the Source and Destination Agent for
  the same managed transfer.
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  Setting the agent property "enableMemoryAllocationChecking" to
  the value true enables memory checking for that agent. When this
  functionality is being used, the agent maintains an internal
  "memory map". The maximum size of the "memory map" is set to the
  maximum heap size of the Java Runtime Environment that the agent
  is running in minus 50MB (which is the amount of memory used by
  an idle agent).
  
  When a new managed transfer request is received by an agent, it
  calculates the maximum amount of memory that will be required
  for the managed transfer to run to completion, and then tries to
  reserve this amount of memory in the "memory map". If the
  "memory map" contains enough space for this managed transfer,
  then the memory is reserved and allocated to the managed
  transfer. The memory is then released in the "memory map" when
  the managed transfer completes.
  
  However, if the "memory map" does not contain enough space for
  the managed transfer, then the agent puts it into recovery and
  the following message is written to the agent's event log:
  
  BFGTR0067I: Transfer ID: <managed transfer identifier> entering
  recovery, after a short pause, due to recoverable error:
  BFGUL0002W: There is insufficient memory available for the
  transfer with transfer id <managed transfer identifier> to run.
  
  When an agent is acting as the Source Agent for a managed
  transfer, the memory is allocated in the "memory map" just
  before the managed transfer starts.
  
  If the agent is acting as the Destination Agent for a managed
  transfer, then it will allocate memory in the "memory map" when
  it receives the managed transfer request from the Source Agent.
  
  
  If an agent was acting as both the Source and Destination Agent
  for the same managed transfer, then the following sequence of
  events would occur:
  
  - The agent started up, and a "memory map" was created with a
  size of x bytes.
  - The agent determined that it needed to allocate y bytes in
  order to act as the Source Agent for the managed transfer.
  - It checked the "memory map", and found that there was enough
  space for this managed transfer.
  - The "memory map" was then updated to indicate that the managed
  transfer would use y bytes of memory. The amount of available
  space in the "memory map" was now (x-y) bytes.
  
    Memory Map
    --------------------------
    Total Size: x bytes
    Allocated Memory : [ManagedTransferA: y bytes]
    Available Memory : x-y bytes
  
  - The agent now determined that it needed to allocate z bytes in
  order to act as the Destination Agent.
  - There was enough space in the "memory map" for this, so the
  entry for this managed transfer in the "memory map" was
  overridden to indicate that it would now use z bytes. However,
  the amount of available space in the "memory map" was now
  (x-y-z) bytes.
  
    Memory Map
    --------------------------
    Total Size: x bytes
    Allocated Memory : [ManagedTransferA: z bytes]
    Available Memory : x-y-z bytes
  
  - The managed transfer completed.
  - In it's role as the Source Agent, the agent released the
  memory allocated to the managed transfer in the "memory map".
  This caused z bytes to be released.
  - The available space in the "memory map" was now (x-y) bytes.
  
    Memory Map
    --------------------------
    Total Size: x bytes
    Allocated Memory : [None]
    Available Memory : x-y bytes
  
  - The agent now tried to free up the memory allocated for the
  Destination Agent side of the managed transfer. However, the
  "memory map" did not contain any information about this managed
  transfer any more, so no additional memory is released.
  
  As a result of this behaviour, the amount of available memory in
  the "memory map" decreased every time a managed transfer
  completed, until it got too small for any new managed transfer
  requests to be processed.
  

Problem conclusion

• The memory checking functionality provided by the MQ V8 Managed
  File Transfer component has been updated to ensure that all of
  the memory allocated to a managed transfer in the "memory map"
  is released once that managed transfer completes.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v8.0       8.0.0.6
  
  The latest available FTE maintenance can be obtained from
  'Fix List for WebSphere MQ File Transfer Edition 7.0'
  http://www-01.ibm.com/support/docview.wss?uid=swg27015313
  
  The latest available MQ 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 MFT V8.0

• Fixed component ID

  5724H7252

Applicable component levels

• R800 PSY

     UP