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 :).
Cheers!
D.
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:
> /*/
> function itemToXML($xml,$item)
>{
> $xml .= ' $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 = '';
>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.'';
> itemToXML(&$xml,$row);
> $xml .= '';
>}
> }
>}
>$xml .= '';
>$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
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
