IV01050: LARGE QUERY RESULT CRASHES TEPS OUT OF MEMORY

IBM Tivoli Monitoring 6.2.2 Fix Pack 8 (6.2.2-TIV-ITM-FP0008)
IBM Tivoli Monitoring 6.2.2 Fix Pack 9 (6.2.2-TIV-ITM-FP0009)
IBM Tivoli Monitoring 6.2.2 Fix Pack 6 (6.2.2-TIV-ITM-FP0006)

APAR status

• Closed as program error.

Error description

• ***************** START OF APAR OPEN TEMPLATE ****************
  * Please open an apar with the following severity and
  information:
  *
  APAR Type:            Field
  Approver Initials:    MB
  Severity:             2
  Reported Release:     622
  Compid:               5724C04PS Tivoli Enterprise Portal Server
  ABSTRACT:             Large query result crashes TEPS out of
  memory
  PROBLEM DESCRIPTION:
  Customer issued a query that returned 1.5 million rows and
  caused the TEPS to run out of memory.
  
  RECREATE INSTRUCTIONS:
  Issue a query that generates a large result set and specify
  return all rows.
  Recreation of the issue:
  
  Logged into TEPS went to linux os workspace, disk usage
  (superseded)
  Changed one of the Tables to return all rows, applied and OK.
  Changed History setting to return last 12 days worth of data.
  KfwServices increased slightly in memory <1%
  Changed the properties of the table and re-assigned the query to
  DISK IO Rates (Superseded).
  Applied and OK.
  
  Changed History setting to return last 12 days worth of data.
  KfwServices increased slightly in memory <0.5%
  Now,  navigated to tx8xptepdb01 disk usage (superseded)
  workspace.
  
  Changed one of the Tables to return all rows, applied and OK.
  Changed the properties of the table and re-assigned the query to
  DISK IO Rates (Superseded).
  Applied and OK.
  
  Changed History setting to return last 12 days worth of data.
  On the TEP client I get hour glass.  Memory steadily starts to
  increase for KfwService.
  
  Then eventually leaps to 82+%
  TEP client gets an error:
  KFWITM354E The Time Span request terminated with the following
  message:
  <KFWITM220E Request failed during execution.>
  Memory then dropped to about 55%.
  
  
  
  LOCAL FIX:
  Do not issue query to return all rows.
  
  ****************** END OF APAR OPEN TEMPLATE ******************
  

Local fix

• Do not issue query to return all rows.
  

Problem summary

• A user can execute a report request that returns a very large
  number of rows, which causes the portal server to run out of
  memory and crash.
  
  A user can create a view on a workspace using a query that will
  return a very large number of rows.  If the user modifies the
  view properties and chooses the option to return all rows for
  the request, the portal server must read all rows into memory
  and convert the data to a form for return to the client.  This
  can cause the portal server process to run out of memory and
  crash, or can cause the system to run out of swap space and
  require a reboot.
  

Problem conclusion

• Added new environment variable to allow an administrator to
  specify a hard limit to the number of rows to return when the
  view has been set to return all rows.
  
  To specify a hard limit, add the following environment variable
  to the portal server environment file:
  
  KFW_REPORT_ROW_LIMIT=###
  
  where ### is an integer representing the maximum number of rows
  to return.  The default value is 100,000 rows.
  
  This variable only affects requests that are configured to
  return all rows.  If a user selects the option to specify an
  explicit number of rows, and sets it to a very large number, the
  hard limit will be ignored, and the number of rows requested
  will be returned.  The hard limit also does not affect
  multi-page results.  If the requested number of rows is less
  than the total number of rows, and the user clicks the button to
  go to the next page, the hard limit will be ignored, and the
  next page of data will be returned.
  
  
  
  The fix for this APAR is contained in the following maintenance
  packages:
  
    | fix pack | 6.2.2-TIV-ITM-FP0006
  

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

  TEPS

• Fixed component ID

  5724C04PS

Applicable component levels

• R622 PSY

     UP