Hi again,
I tested Quercus 3.1.6 on Resin 3.1.5, and the memory leak is still there.
As I'm not using PHP in production, just as a showcase, and it seems 
nobody else is affected or cares about the leak, I won't probably be 
doing further tests. I just wanted to do these last set of tests in case 
the leak had been fixed in 3.1.6 and that explained the lack of response :).


Daniel López escribió:
> Hi,
> 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.

resin-interest mailing list

Reply via email to