[Resin-interest] Quercus + Scripting API memory issue [still present in Quercus 3.1.6]
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
[Resin-interest] HttpSession.invalidate() doesn't
Hi list, I'm using resin-pro-3.0.25 in a three-server cluster with session persistence configured using a MySQL database: persistent-store type=jdbc init data-sourcejdbc/session/data-source always-load / always-save / /init /persistent-store What I'm finding is that you can click logout up to 7 or 8 times before your session actually gets invalidated. The implementation of HttpSessionListener is doing its thing. The logout servlet is doing its thing but from what I can see the req.getSession().invalidate() call is NOT being respected. Little help? rgds, Richard PS. I am loath to switch (back) to using clustered sessions as I've had issues with random logouts and loads of timeout errors in the logs related to the internal Resin session store. Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd 4th Floor 1 London Bridge London SE1 9BG Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] SOAP in Resin
PS; It seems that PHP does not support SoapClient neither! We have to use third party PHP packages such as nusoap? Regards. -- View this message in context: http://www.nabble.com/SOAP-in-Resin-tp17659264p17894048.html Sent from the Resin mailing list archive at Nabble.com. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Quercus + Scripting API memory issue [still present in Quercus 3.1.6]
Date: Tue, Jun 17, 2008 at 10:20:12AM +0200 Subject: [Resin-interest] Quercus + Scripting API memory issue [still present in Quercus 3.1.6] 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 :). There is a bug report for this issue here: http://bugs.caucho.com/view.php?id=2709 Is there anything wrong in the code above that might cause the leak? Unless the PHP script explicitly instantiates or uses a Java object there should be no possibility of a memory leak from a PHP script. If the script is just using straight PHP then any memory leak is a Quercus bug. It is probably the case that the current implementation of the javax.script api is not properly cleaning things up when the script api is used in the pattern you described. Great report, BTW. -- Sam ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] HttpSession.invalidate() doesn't
I'm using resin-pro-3.0.25 in a three-server cluster with session persistence configured using a MySQL database: persistent-store type=jdbc init data-sourcejdbc/session/data-source always-load / always-save / /init /persistent-store What I'm finding is that you can click logout up to 7 or 8 times before your session actually gets invalidated. The implementation of HttpSessionListener is doing its thing. The logout servlet is doing its thing but from what I can see the req.getSession().invalidate() call is NOT being respected. I believe that problem is addressed in 3.0.26, issue #2485 reported in the change log here: http://www.caucho.com/resin-3.0/features/changes.xtp PS. I am loath to switch (back) to using clustered sessions as I've had issues with random logouts and loads of timeout errors in the logs related to the internal Resin session store. There were a number if cluster store issues reported in the 3.1 branch, but the remaining issues in 3.0 have generally not been reported to us, we found them by doing increased stress testing for the 3.1 release. Take care, -- Sam ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] HttpSession.invalidate() doesn't
Thanks Sam. I'll give it a go. Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd 4th Floor 1 London Bridge London SE1 9BG Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments.-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Sent: 17 June 2008 14:17 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] HttpSession.invalidate() doesn't I'm using resin-pro-3.0.25 in a three-server cluster with session persistence configured using a MySQL database: persistent-store type=jdbc init data-sourcejdbc/session/data-source always-load / always-save / /init /persistent-store What I'm finding is that you can click logout up to 7 or 8 times before your session actually gets invalidated. The implementation of HttpSessionListener is doing its thing. The logout servlet is doing its thing but from what I can see the req.getSession().invalidate() call is NOT being respected. I believe that problem is addressed in 3.0.26, issue #2485 reported in the change log here: http://www.caucho.com/resin-3.0/features/changes.xtp PS. I am loath to switch (back) to using clustered sessions as I've had issues with random logouts and loads of timeout errors in the logs related to the internal Resin session store. There were a number if cluster store issues reported in the 3.1 branch, but the remaining issues in 3.0 have generally not been reported to us, we found them by doing increased stress testing for the 3.1 release. Take care, -- Sam ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Problem with Resin 3.1.6 Pro and keepalive
Hi
I have a test-server that runs a mix of Resin 2.1.17 and 3.0.23 Pro (havn't had
a reason to upgrade yet) using 2 different Apache 2.2 instances as frontends
for several vhosts on RHEL3u9 (2.4.21-50) with JDK1.6.0_03.
This setup is just fine, and performs as expected for all my needs.Howver I'm
in the process of rolling out Resin 3.1.6 Pro on a new server (since the 3.1
branch it's now stable I might as well upgrade).
I've set everything up - added a new Apache instance for the 3.1.6 version of
mod_caucho.so etc. - and started up a site. In resin.conf (see below) I've used
the stdout-log-tag to output to logs/resin-stdout.log, and the
stderr-log-tag to logs/resin-stderr.log.
Upon startup of a site this is written to resin-stdout.log:
[2008-06-17 16:28:01.467][16:28:01.467] Linux 2.4.21-50.EL i386
[2008-06-17 16:28:01.467][16:28:01.467] Java(TM) SE Runtime Environment
1.6.0_03-b05, ISO-8859-1, en
[2008-06-17 16:28:01.468][16:28:01.467] Java HotSpot(TM) Server VM
1.6.0_03-b05, 32, mixed mode, Sun Microsystems Inc.
[2008-06-17 16:28:01.468][16:28:01.468] user.name: root
[2008-06-17 16:28:01.468][16:28:01.468] resin.home =
/usr/local/resin/resin-pro-3.1.6/
[2008-06-17 16:28:01.469][16:28:01.469] resin.root = /usr/local/www/results_test
[2008-06-17 16:28:01.469][16:28:01.469] resin.conf =
/usr/local/www/results_test/conf/resin.conf
[2008-06-17 16:28:01.469][16:28:01.469]
[2008-06-17 16:28:16.800][16:28:16.800] Loaded Socket JNI library.
[2008-06-17 16:28:16.804][16:28:16.804] hmux listening to
localhost.localdomain:6875
[2008-06-17 16:28:16.816][16:28:16.816] Server[id=results_test,cluster=web]
active
[2008-06-17 16:28:16.818][16:28:16.818] Resin started in 17788ms
So far so good, however this also appears in resin-stderr.log at the same time:
[2008-06-17 16:28:01.507]Exception in thread resin-select-manager
java.io.IOException: failed to add EPOLL for pipe=47 (errno=-1)
[2008-06-17 16:28:01.508] at
com.caucho.server.port.JniSelectManager.initNative(Native Method)
[2008-06-17 16:28:01.508] at
com.caucho.server.port.JniSelectManager.run(JniSelectManager.java:274)
[2008-06-17 16:28:01.508] at java.lang.Thread.run(Thread.java:619)
Then upon accessing the site this appears in logs/resin-stdout.log:
[2008-06-17 16:28:18.377][16:28:18.377] Tcp[results_test,0] failed keepalive
(select)
[2008-06-17 16:28:32.685][16:28:32.684] Tcp[results_test,1] failed keepalive
(select)
[2008-06-17 16:28:32.705][16:28:32.705] Tcp[results_test,2] failed keepalive
(select)
[2008-06-17 16:28:32.725][16:28:32.725] Tcp[results_test,3] failed keepalive
(select)
[2008-06-17 16:28:32.754][16:28:32.754] Tcp[results_test,4] failed keepalive
(select)
[2008-06-17 16:28:32.785][16:28:32.784] Tcp[results_test,5] failed keepalive
(select)
[2008-06-17 16:28:32.825][16:28:32.825] Tcp[results_test,6] failed keepalive
(select)
.. and the site changes between a 503-error page (as if the site isn't started)
and a working site (using refresh in the browser a few times), so it's
obviously not working as it should.
This is my resin.conf:
resin xmlns=http://caucho.com/ns/resin;
xmlns:resin=http://caucho.com/ns/resin/core;
management
user name=xxx password=/
/management
stdout-log path=/usr/local/www/results_test/logs/resin-stdout.log
timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D/
stderr-log path=/usr/local/www/results_test/logs/resin-stderr.log
timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D/
log name= level=config path=stdout: timestamp=[%H:%M:%S.%s] /
logger name=com.caucho.java level=config/
logger name=com.caucho.loader level=config/
thread-pool
thread-max150/thread-max
spare-thread-min5/spare-thread-min
/thread-pool
cluster id=web
server-default
jvm-arg-Xmn32m/jvm-arg
jvm-arg-Xms64m/jvm-arg
jvm-arg-Xmx512m/jvm-arg
jvm-arg-server/jvm-arg
jvm-arg-XX:-OmitStackTraceInFastThrow/jvm-arg
/server-default
server id=results_test address=127.0.0.1 port=6875
watchdog-port7875/watchdog-port
keepalive-max100/keepalive-max
keepalive-timeout30s/keepalive-timeout
bind-ports-after-starttrue/bind-ports-after-start
/server
ignore-client-disconnecttrue/ignore-client-disconnect
host id= root-directory=/usr/local/www/results_test
class-loader
compiling-loader path=site/WEB-INF/classes/
library-loader path=site/WEB-INF/lib/
/class-loader
access-log path=/usr/local/www/results_test/logs/resin-access.log
format='%h %l %u %t %r %s %b %{Referer}i %{User-Agent}i'
rollover-period=1D/
stdout-log path=/usr/local/www/results_test/logs/resin-web-stdout.log
timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D/
stderr-log path=/usr/local/www/results_test/logs/resin-web-stderr.log
timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D/
web-app id=/ document-directory=site
resin:import path=WEB-INF/web.xml/
Re: [Resin-interest] Problem with Resin 3.1.6 Pro and keepalive
On Jun 17, 2008, at 9:47 AM, Jens Dueholm Christensen wrote:
So far so good, however this also appears in resin-stderr.log at the
same time:
[2008-06-17 16:28:01.507]Exception in thread resin-select-manager
java.io.IOException: failed to add EPOLL for pipe=47 (errno=-1)
[2008-06-17 16:28:01.508] at
com.caucho.server.port.JniSelectManager.initNative(Native Method)
[2008-06-17 16:28:01.508] at
com.caucho.server.port.JniSelectManager.run(JniSelectManager.java:274)
[2008-06-17 16:28:01.508] at java.lang.Thread.run(Thread.java:
619)
Can you try setting keepalive-select-enable=false in the server:
resin ...
...
cluster id=
...
server id=
http port=80/
keepalive-select-enablefalse/keepalive-select-enable
...
I believe your older Linux version doesn't correctly support EPOLL,
which the select manager uses to handle keepalives.
-- Scott
Then upon accessing the site this appears in logs/resin-stdout.log:
[2008-06-17 16:28:18.377][16:28:18.377] Tcp[results_test,0] failed
keepalive (select)
[2008-06-17 16:28:32.685][16:28:32.684] Tcp[results_test,1] failed
keepalive (select)
[2008-06-17 16:28:32.705][16:28:32.705] Tcp[results_test,2] failed
keepalive (select)
[2008-06-17 16:28:32.725][16:28:32.725] Tcp[results_test,3] failed
keepalive (select)
[2008-06-17 16:28:32.754][16:28:32.754] Tcp[results_test,4] failed
keepalive (select)
[2008-06-17 16:28:32.785][16:28:32.784] Tcp[results_test,5] failed
keepalive (select)
[2008-06-17 16:28:32.825][16:28:32.825] Tcp[results_test,6] failed
keepalive (select)
.. and the site changes between a 503-error page (as if the site
isn't started) and a working site (using refresh in the browser a
few times), so it's obviously not working as it should.
This is my resin.conf:
resin xmlns=http://caucho.com/ns/resin;
xmlns:resin=http://caucho.com/ns/resin/core
management
user name=xxx password=/
/management
stdout-log path=/usr/local/www/results_test/logs/resin-
stdout.log timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D/
stderr-log path=/usr/local/www/results_test/logs/resin-
stderr.log timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D/
log name= level=config path=stdout: timestamp=[%H:%M:%S.%s]
/
logger name=com.caucho.java level=config/
logger name=com.caucho.loader level=config/
thread-pool
thread-max150/thread-max
spare-thread-min5/spare-thread-min
/thread-pool
cluster id=web
server-default
jvm-arg-Xmn32m/jvm-arg
jvm-arg-Xms64m/jvm-arg
jvm-arg-Xmx512m/jvm-arg
jvm-arg-server/jvm-arg
jvm-arg-XX:-OmitStackTraceInFastThrow/jvm-arg
/server-default
server id=results_test address=127.0.0.1 port=6875
watchdog-port7875/watchdog-port
keepalive-max100/keepalive-max
keepalive-timeout30s/keepalive-timeout
bind-ports-after-starttrue/bind-ports-after-start
/server
ignore-client-disconnecttrue/ignore-client-disconnect
host id= root-directory=/usr/local/www/results_test
class-loader
compiling-loader path=site/WEB-INF/classes/
library-loader path=site/WEB-INF/lib/
/class-loader
access-log path=/usr/local/www/results_test/logs/resin-
access.log format='%h %l %u %t %r %s %b %{Referer}i %{User-
Agent}i' rollover-period=1D/
stdout-log path=/usr/local/www/results_test/logs/resin-web-
stdout.log timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D/
stderr-log path=/usr/local/www/results_test/logs/resin-web-
stderr.log timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D/
web-app id=/ document-directory=site
resin:import path=WEB-INF/web.xml/
session-config
session-max16384/session-max
enable-cookiestrue/enable-cookies
enable-url-rewritingtrue/enable-url-rewriting
/session-config
servlet servlet-name=resin-file servlet-
class=com.caucho.servlets.FileServlet/
servlet servlet-name=resin-jsp servlet-
class=com.caucho.jsp.JspServlet
init
load-tld-on-initfalse/load-tld-on-init
page-cache-max1024/page-cache-max
/init
load-on-startup/
/servlet
!-- invoker servlet for all standard WebPages and
WebCommands--
servlet-mapping url-pattern=/servlet/* servlet-
name=invoker/
servlet-mapping url-pattern=*.jsp servlet-name=resin-jsp/
... context params removed...
/web-app
/host
/cluster
/resin
I've looked at http://bugs.caucho.com/view.php?id=2555
http://bugs.caucho.com/view.php?id=2555
(first and almost onle relevant hit when googling for resin
failed keepalive and variations) and tried to add the keepalive-
select-max-tag, but to no avail (and I can't seem to find any
documentation on that tag?).
I think it's somehow related to the Exception in resin-select-
manager at startup, but I'm not sure, and
Re: [Resin-interest] Problem with Resin 3.1.6 Pro and keepalive
Hi Scott
That seems to have done the trick!
A bit more digging told me, that epoll(4) was introduced around 2.5.44, so that
was spot on - thanks for the hint!
Apart from the increased usage of sockets (or so I understand it from
http://www.caucho.com/resin/doc/server-tags.xtp#keepalive-select-enable) there
shouldn't be any other sideeffects?
Oh well - seems like I should start working on upgrading my testserver.. :)
Regards,
Jens Dueholm Christensen
Rambøll survey IT
From: [EMAIL PROTECTED] on behalf of Scott Ferguson
Sent: Tue 6/17/2008 19:07
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Problem with Resin 3.1.6 Pro and keepalive
On Jun 17, 2008, at 9:47 AM, Jens Dueholm Christensen wrote:
So far so good, however this also appears in resin-stderr.log at the
same time:
[2008-06-17 16:28:01.507]Exception in thread resin-select-manager
java.io.IOException: failed to add EPOLL for pipe=47 (errno=-1)
[2008-06-17 16:28:01.508] at
com.caucho.server.port.JniSelectManager.initNative(Native Method)
[2008-06-17 16:28:01.508] at
com.caucho.server.port.JniSelectManager.run(JniSelectManager.java:274)
[2008-06-17 16:28:01.508] at java.lang.Thread.run(Thread.java:
619)
Can you try setting keepalive-select-enable=false in the server:
resin ...
...
cluster id=
...
server id=
http port=80/
keepalive-select-enablefalse/keepalive-select-enable
...
I believe your older Linux version doesn't correctly support EPOLL,
which the select manager uses to handle keepalives.
-- Scott
Then upon accessing the site this appears in logs/resin-stdout.log:
[2008-06-17 16:28:18.377][16:28:18.377] Tcp[results_test,0] failed
keepalive (select)
[2008-06-17 16:28:32.685][16:28:32.684] Tcp[results_test,1] failed
keepalive (select)
[2008-06-17 16:28:32.705][16:28:32.705] Tcp[results_test,2] failed
keepalive (select)
[2008-06-17 16:28:32.725][16:28:32.725] Tcp[results_test,3] failed
keepalive (select)
[2008-06-17 16:28:32.754][16:28:32.754] Tcp[results_test,4] failed
keepalive (select)
[2008-06-17 16:28:32.785][16:28:32.784] Tcp[results_test,5] failed
keepalive (select)
[2008-06-17 16:28:32.825][16:28:32.825] Tcp[results_test,6] failed
keepalive (select)
.. and the site changes between a 503-error page (as if the site
isn't started) and a working site (using refresh in the browser a
few times), so it's obviously not working as it should.
This is my resin.conf:
resin xmlns=http://caucho.com/ns/resin;
xmlns:resin=http://caucho.com/ns/resin/core
management
user name=xxx password=/
/management
stdout-log path=/usr/local/www/results_test/logs/resin-
stdout.log timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D/
stderr-log path=/usr/local/www/results_test/logs/resin-
stderr.log timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D/
log name= level=config path=stdout: timestamp=[%H:%M:%S.%s]
/
logger name=com.caucho.java level=config/
logger name=com.caucho.loader level=config/
thread-pool
thread-max150/thread-max
spare-thread-min5/spare-thread-min
/thread-pool
cluster id=web
server-default
jvm-arg-Xmn32m/jvm-arg
jvm-arg-Xms64m/jvm-arg
jvm-arg-Xmx512m/jvm-arg
jvm-arg-server/jvm-arg
jvm-arg-XX:-OmitStackTraceInFastThrow/jvm-arg
/server-default
server id=results_test address=127.0.0.1 port=6875
watchdog-port7875/watchdog-port
keepalive-max100/keepalive-max
keepalive-timeout30s/keepalive-timeout
bind-ports-after-starttrue/bind-ports-after-start
/server
ignore-client-disconnecttrue/ignore-client-disconnect
host id= root-directory=/usr/local/www/results_test
class-loader
compiling-loader path=site/WEB-INF/classes/
library-loader path=site/WEB-INF/lib/
/class-loader
access-log path=/usr/local/www/results_test/logs/resin-
access.log format='%h %l %u %t %r %s %b %{Referer}i %{User-
Agent}i' rollover-period=1D/
stdout-log path=/usr/local/www/results_test/logs/resin-web-
stdout.log timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D/
stderr-log path=/usr/local/www/results_test/logs/resin-web-
stderr.log timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D/
web-app id=/ document-directory=site
resin:import path=WEB-INF/web.xml/
session-config
session-max16384/session-max
enable-cookiestrue/enable-cookies
enable-url-rewritingtrue/enable-url-rewriting
/session-config
servlet servlet-name=resin-file servlet-
class=com.caucho.servlets.FileServlet/
servlet servlet-name=resin-jsp servlet-
class=com.caucho.jsp.JspServlet
init
load-tld-on-initfalse/load-tld-on-init
page-cache-max1024/page-cache-max
/init
load-on-startup/
/servlet
!-- invoker
[Resin-interest] Serious jsp:useBean bug?
Hi, As we are discussing some other issues, we found a potential serious problem with jsp:useBean. Basically, if useBean only has the type parameter but not the class/bean parameters, the resin server will fail because it does not know what to instantiate, contrary to the spec. !-- should set foo to null but fail instead. -- jsp:useBean id=foo type=java.lang.String scope=request/ For the full discussion of the bug and the JSP spec, see http://www.jetbrains.net/jira/browse/IDEA-18405 The strange thing is that Tomcat behaves the same. So I wonder if this is a bug or a legacy problem for the servers due to confusing descriptions in earlier JSP spec? Please enlighten me! Thanks ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Serious jsp:useBean bug?
On Jun 17, 2008, at 11:51 AM, Hacking Bear wrote: Hi, As we are discussing some other issues, we found a potential serious problem with jsp:useBean. Basically, if useBean only has the type parameter but not the class/bean parameters, the resin server will fail because it does not know what to instantiate, contrary to the spec. !-- should set foo to null but fail instead. -- jsp:useBean id=foo type=java.lang.String scope=request/ How is that contrary to the spec? JSP.5.1 5. If the object is not found in the specified scope and neither class or beanName are given, a java.lang.InstantiationException shall occur. This completes the processing of thisjsp:useBean action. -- Scott For the full discussion of the bug and the JSP spec, see http://www.jetbrains.net/jira/browse/IDEA-18405 The strange thing is that Tomcat behaves the same. So I wonder if this is a bug or a legacy problem for the servers due to confusing descriptions in earlier JSP spec? Please enlighten me! Thanks ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] very long restart time
HI List, I have began to notice some strangeness when deploying my war files to my production environment. This is my scenario: I have a 2 server clustered setup. Resin 3.1.3 pro. Previously, my deployments for new versions was simply push out the new war file and wait for the watchdog to notice the file change. Then resin would expand the file and the server would typically restart in 10 seconds or less. Lately, I have been plagued with extremely long re-start times. And I mean realy long. On my last deployment, resin took roughly 20 mintues to start! The output shows that resin appears to hang during the expanding war file stage (or atleast that the message that appears before it hangs). Eventually, after a long enough wait, the process gets past that step and things expand and deploy properly. In one instance, when this occurred, I decided not to wait for the on the fly restart. So i killed the java /resin process and started the process from scratch. The restart was still very slow. I know I'm not giving a lot of info here, but I'm not even sure where to begin tracking this down. Anyone seen anything like this, or got any advice how to track this down? regards, Sandeep ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Serious jsp:useBean bug?
Hmm... You are correct that this is the behavior described by the real spec. Even though the JSP reference card on Sun's website clearly state a different behavior. http://java.sun.com/products/jsp/syntax/2.0/syntaxref2027.html#8865 I guest we can only blame the reference card. :-) On Tue, Jun 17, 2008 at 1:29 PM, Scott Ferguson [EMAIL PROTECTED] wrote: On Jun 17, 2008, at 12:42 PM, Hacking Bear wrote: See in the discussion link You need to address the section I quoted from the spec. It is extremely clear: 5. If the object is not found in the specified scope and neither class nor beanName are give, a java.lang.InstantiationException shall occur. This completes the processing of this jsp:useBean action. There is zero ambiguity in that rule. However, you may be right that the tag lib spec allows the use of type attribute only. In http://java.sun.com/products/jsp/tags/11/syntaxref11.fm14.html , it first says If the Bean does not exist, jsp:useBean instantiates it from a class or serialized template. and then on the attribute description: That page is not part of the spec. Also, it appears to be for JSP 1.1. Here are some relevant snippets from the JSP 2.1 spec. However, as far as I know the sections haven't changed for either 2.0 or 2.1 versions: *(section JSP 5.1, jsp:useBean)* It is also possible to use this action to give a local name to an object defined elsewhere, as in another JSP page or in a servlet. This can be done by using the type attribute and not providing class or beanName attributes. You're quoting from non-normative explanatory/example text. The language is looser. The Semantics section is the precisely defined, normative section of the spec. In the final example, the object should have been present in the session. If so, it is given the local name wombat with WombatType. A ClassCastException may be raised if the object is of the wrong class, and an InstantiationException may be raised if the object is not defined. That doesn't contradict rule #5 at all. It says an InstantiationException will be raised if the object isn't defined. (And since it's from explanatory text, the language is looser than the language in the Semantics section, i.e. the correct word is shall, not may.) jsp:useBean id=wombat type=my.WombatType scope=session/ And for all practical purposes, useBean should allow setting the variable to null because many classes are bean-like and not strict JavaBean and it is also harder to tell if it is an valid bean or an empty bean. Should has nothing to do with specifications. There is only does and does not. There is no should. (Well, ignoring optional, but highly recommended sections of a spec, which doesn't apply in this case.) -- Scott On Tue, Jun 17, 2008 at 12:09 PM, Scott Ferguson [EMAIL PROTECTED] wrote: On Jun 17, 2008, at 11:51 AM, Hacking Bear wrote: Hi, As we are discussing some other issues, we found a potential serious problem with jsp:useBean. Basically, if useBean only has the type parameter but not the class/bean parameters, the resin server will fail because it does not know what to instantiate, contrary to the spec. !-- should set foo to null but fail instead. -- jsp:useBean id=foo type=java.lang.String scope=request/ How is that contrary to the spec? JSP.5.1 5. If the object is not found in the specified scope and neither class or beanName are given, a java.lang.InstantiationException shall occur. This completes the processing of thisjsp:useBean action. -- Scott For the full discussion of the bug and the JSP spec, see http://www.jetbrains.net/jira/browse/IDEA-18405 The strange thing is that Tomcat behaves the same. So I wonder if this is a bug or a legacy problem for the servers due to confusing descriptions in earlier JSP spec? Please enlighten me! Thanks ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
