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:
/*/
?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
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
