0002709: quercus script leak

Viewing Issue Advanced Details [ Jump to Notes ]

[ View Simple ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0002709

[Quercus]

minor

always

05-29-08 14:24

09-05-08 08:18

Reporter

ferg

View Status

public

Assigned To

Priority

high

Resolution

fixed

Platform

Status

closed

Projection

none

OS Version

ETA

none

Fixed in Version

3.2.1

Product Version

3.1.6

Product Build

Summary

0002709: quercus script leak

Description

(rep by Daniel Lopez)

Doing some tests with the application I use to test my framework, I seem
to have come across a memory leak in Quercus, or at least caused by the
way I'm using it (through the scripting API and returning a String).

Basically what the suspect operation does is perform a call to a PHP
script that is interpreted with Quercus and returns a String,
representing some XML. While running the tests using YourKit, you can
see that the memory keeps growing and even calling the GC explicitely
does not bring it back to lower levels. When the JVM reaches it's limit,
it starts to strugle at the limit and GC starts using up to 90% of the
CPU time but it never gets lower than 1-2MB from the limit.

After taking a snapshot, one of the more suspect classes that seem to be
holding memory when they shouldn't is java.io.BufferedWriter(through
char[]) ... with >90% of the instances traced back to
javax.script.SimpleScriptContext and from there to
com.caucho.quercus.env.Env and
com.caucho.quercus.script.QuercusScriptEngine.

There are other classes that remain there associated with the
com.caucho.quercus.* packages that seem they needen't be there after
being used, but that's just the biggest memory-eater.

After seeing that, I run exactly the same tests in the same environment,
but simply not calling the PHP script but all the other tests and the
memory remained at a steady level. I re-enabled the PHP test and the
memory started growing again.

In case the problem is that I'm doing something wrong with the PHP code,
the code is this one:
/*********************************************/
<?php
  function itemToXML($xml,$item)
  {
    $xml .= '<ITEM ';
    $xml .= 'Code="'.$item['ITE_CODE'].'" ';
    $xml .= 'Name="'.$item['ITE_NAME'].'" ';
    $xml .= 'Description="'.$item['ITE_DESCRIPTION'].'" ';
    $xml .= '/>';
  }

  $pdo = new PDO("java:comp/env/jdbc/Test");

  $sql = "select * from TTST_ITEM ORDER BY ITE_NAME";

  // First query all the objects
  $xml = '<ITEM_QUERY Type="All" Impl="PHP">';
  foreach ($pdo->query($sql) as $row)
  {
    itemToXML(&$xml,$row);
  }
  if($param['ite_code'])
  {
    $stmt = $pdo->prepare("select * from TTST_ITEM where ITE_CODE =
:ite_code");
    $stmt->bindParam(':ite_code', (string)$param['ite_code']);
    if ($stmt->execute())
    {
      while ($row = $stmt->fetch())
      {
        $xml = $xml.'<ITEM_QUERY Type="Selected">';
        itemToXML(&$xml,$row);
        $xml .= '</ITEM_QUERY>';
      }
    }
  }
  $xml .= '</ITEM_QUERY>';
  $pdo->close();
  return (string)$xml;
?>
/*********************************************/
The code is called through the Java 6 Scripting API, and the Scripting
Engine is being kept in the servlet context not to look it up for each
call. A new ScriptContext is created for each call to pass the parameters.
The other requests use the same datasource and perform the same queries,
produce the same XML that is processed using the same library,
freemarker, and the same template file. That's why all the signs point
to something going wrong with this specific request.
Is there anything wrong in the code above that might cause the leak? I'm
not a PHP expert so it could be my fault for not doing things properly,
hence my question. The Java 6 Scripting API code that calls the PHP is
pretty simple, so I don't think the problem is in there. The other
plausible option seems to be some kind of lingering reference to the
parameters, the return value of the script or the script itself from the
quercus engine, may be just when used through the Scripting API.

All of this has been tested with Resin 3.1.5 and the Quercus version
included with it, as the DataSource order initialisation issue prevented
me from using the latest release (3.1.6).

I did not see any issue that sounded like that in Mantis.

Anybody else tried using PHP/Quercus through the Scripting API?

Cheers!
D.

PD: All the code used to test, including the framework that performs the
calls and the test application, is open, so it can be reproduced.
https://webleaf.dev.java.net/ [^]
https://webleaftest.dev.java.net/ [^]
PPD: I have the memory dumps in YourKit Profiler format, in case they
are useful. I can get some in HPROF format as well if necessary.

Steps To Reproduce

Additional Information

Attached Files

Relationships

Notes
(0003207) GreenEyed 06-17-08 23:52	Tested also with Quercus 3.1.6 on Resin 3.1.5 to workaround Resin 3.1.6's issue with datasources. No change, leak still present.

(0003392) emil 09-05-08 08:18	php/2125 php/214g

Issue History
Date Modified	Username	Field	Change
05-29-08 14:24	ferg	New Issue
06-17-08 06:04	sam	Priority	normal => high
06-17-08 23:52	GreenEyed	Note Added: 0003207
09-05-08 08:18	emil	Status	new => closed
09-05-08 08:18	emil	Note Added: 0003392
09-05-08 08:18	emil	Resolution	open => fixed
09-05-08 08:18	emil	Fixed in Version	=> 3.2.1

Mantis 1.0.0rc3[^]

33 total queries executed.
29 unique queries executed.