PK51476: Crystal Report Application Server (RAS) memory growth reaching 2 GB in CQ 7.0.0.1

APAR status

• Closed as Vendor Solution.

Error description

• cq_version : 7.0
  cq_build : 7.0.0.1 + BALTIC_PATCH.D060929
  Client_OS_Vendor : Windows
  Client_OS_version : XP
  cq_dbvendor : SQL SERVER 2000
  DB_server_OS_Vendor : Windows
  cq_web_os : Windows
  Web_server_OS_Version : 2003 Server
  cqwj_version : 7.0
  cqwj_build : 7.0.0.1 + BALTIC_PATCH.D060929
  Crystal Reports Server (CEEE) 11 being used.
  -Licensing server is running on the same web server machine.
  RAS server memory growth reached over 2GB.  Vincent tested the
  RAS memory growth issue on CR10 using large reports and it was
  releasing most of the consumed memory after the connection
  timeout was reached, BO XI was also similarly releasing memory
  (tested using small and medium reports due to oustanding socket
  errors against large reports), although both did not release
  100% of the memory consumed
  Business Objects (BOBJ) suggested to apply the Service Pack 3 on
  RAS XI, but customer still experienced RAS memory growth again
  reaching 2GB
  RAS server memory continues to grow with each additional report
  executed, and is never released until
  the RAS server crashes or is restarted.
  BOBJ ticket #: 302803298
  BOBJ has closed the ticket and indicated that part of the
  problem is on our end. The CQ 7.1 Beta program that is coming
  out in the fall is part of IBM's attempt to resolve the issue.
  Based on the fact that BOBJ is unable to resolve the issue in a
  current release. Below are some modifications they are
  suggesting that we make to our code in order to alleviate the
  issue. There is an open defect with BOBJ as well. The inference
  from below is that they're getting their data using Java
  Serialization - i.e., they're reading Java ObjectInputStream for
  the ResultSet, where the object stream is connected either to a
  wire or a file - so converting to JavaBeans may be relatively
  straightforward.
  IT Admin advantages of converting:
  1. JavaBeans will allow them to keep their Tomcat process memory
  footprint slim. They'll be able to tune their JavaServer memory
  footprint separately.
  2. Won't have 20MB of data being passed from their source to
  Tomcat to RAS, with multiple copies being made at each machine.
  3. With pull, RAS will cache data - refresh time interval is
  controllable.
  Possible issues:
  1. If they're collecting client-side info to affect the
  ResultSet being injected into the report, then they may have to
  redesign reports to handle that internally within the JavaBeans
  code.
  2. I think JavaServer still has an old issue where connection
  attempts fail if an attempt is made just after a JavaServer
  child java process times out. Workaround is to prevent
  JavaServer processes from timing out.
  Also:
  Brian comments that deserialization consumes up to 100MB of data
  - what's the memory consumption after they 'close' the
  ObjectInputStream and garbage-collect? I'm wondering if some of
  the 100MB is taken up by the internal state of the stream that's
  still open after the readObject method call. Sun JFC Object
  serialization isn't slim - I don't know about IBM's
  BOBJ Final Update regarding the RAS Memory growth issue:
  This is too big of a change to release as a patch. Meaning they
  would have to restructure the RAS database components to handle
  large data sets of this size and is outside the scope as a
  patch.
  Possible solutions:
  1. Reduce the amount of data so the engine can handle the memory
  easier, may not be a solution but it will take much longer to
  use up the resources.
  2. There was a suggestion to use the JDBC driver as your data
  source.
  3.Other than this as noted by PM group there is nothing we can
  reasonably do to fix this issue in the XI or XI R2 or the next
  release. It's planned for a future fix tho
  IBM Product Management Response to BOBJ issue:
  It does not seem like BOBJ has any simple suggestions to solve
  the problem in a timely manner.
  Fortunately, it looks like we are on the right track with our
  7.1 development. For 7.1, we are moving to a data-pull model via
  a JDBC driver. The information provided by BOBJ indicates that
  usage of the pull model should solve this problem. Some manual
  steps will be necessary to migrate existing reports from the
  push model to the pull model. Unfortunately, we won't be
  delivering that functionality until 7.1 ships in 2008. A 7.1
  beta is scheduled for November. Perhaps BP would be a good
  candidate for that?
  Customer agreed to participate in the CQ 7.1 Beta release in
  November.
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• The Crystal RAS Server experiences frequent performance
  slowdowns and crashes when memory consumption reaches the
  2GB range, this is a limitation of the Crystal RAS and will
  not be addressed by Rational.
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels