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 

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:
   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)
     $stmt = $pdo->prepare("select * from TTST_ITEM where ITE_CODE = 
     $stmt->bindParam(':ite_code', (string)$param['ite_code']);
     if ($stmt->execute())
       while ($row = $stmt->fetch())
         $xml =  $xml.'<ITEM_QUERY Type="Selected">';
         $xml .= '</ITEM_QUERY>';
   $xml .= '</ITEM_QUERY>';
   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?


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.
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.

resin-interest mailing list

Reply via email to