DO NOT REPLY [Bug 49726] New: JSP 2.2 new configuration element default-content-type under jsp-property-group works incorrectly on tomcat trunk
https://issues.apache.org/bugzilla/show_bug.cgi?id=49726 Summary: JSP 2.2 new configuration element default-content-type under jsp-property-group works incorrectly on tomcat trunk Product: Tomcat 7 Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Jasper AssignedTo: dev@tomcat.apache.org ReportedBy: rafaa.w...@gmail.com Created an attachment (id=25863) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25863) There are no java files in this project, so I only uploaded the war file. And its importance is the web.xml file. I wrote a test case which have been attached to test some new configuration elements under jsp-property-group which are added in JSP2.2. But it runs incorrectly. The error stack: org.apache.jasper.JasperException: /defaultCtype/page1.jsp(17,1) Page directive: illegal to have multiple occurrences of contentType with different values (old: text/xml, new: text/html) org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:236) org.apache.jasper.compiler.Validator$DirectiveVisitor.visit(Validator.java:133) org.apache.jasper.compiler.Node$PageDirective.accept(Node.java:590) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2428) org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2434) org.apache.jasper.compiler.Node$Root.accept(Node.java:475) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376) org.apache.jasper.compiler.Validator.validateDirectives(Validator.java:1733) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:195) org.apache.jasper.compiler.Compiler.compile(Compiler.java:360) org.apache.jasper.compiler.Compiler.compile(Compiler.java:340) org.apache.jasper.compiler.Compiler.compile(Compiler.java:327) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:594) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:315) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265) javax.servlet.http.HttpServlet.service(HttpServlet.java:668) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [g...@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
On 2010-08-09, Bill Barker wrote: From: Stefan Bodewig bode...@apache.org this is due to a configuration error in Gump that I caused - fixed now. I can't find the fix on the Gump list, http://svn.apache.org/viewvc/gump/metadata/project/tomcat-trunk.xml?r1=980289r2=983516 I've modified junit's project descriptor so that junit now publishes two jars (I added junit-dep.jar which is JUnit without Hamcrest) but forgot to search for property references which now need a jar id so Gump knows which jar to reference. Stefan - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49721] Fail to access the resources such as jsp files from a jar file which is supported by servlet 3.0
https://issues.apache.org/bugzilla/show_bug.cgi?id=49721 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com 2010-08-09 06:01:22 EDT --- Probably your jar does not have a META-INF/web-fragment.xml file and thus is skipped. You can look at jar files in webapp-3.0-fragments test webapp for a working example, http://svn.apache.org/repos/asf/tomcat/trunk/test/webapp-3.0-fragments/WEB-INF/lib/ -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Sharing Native Library from parent classloader?
2010/8/7 Brock Noland bro...@gmail.com:
Hello,
I have a legacy application written in C. The library is wrapped in JAVA as
the supporting applications are all JAVA based. The problem we are running
into is that although the library is thread safe the java wrapper is not.
Changing the wrapper would be a major change. As such, we have to run many
JVMs on a single host which is eating memory like crazy. We have tens of
thousands of these JVMs. My goal is to wrap around the non-thread safe
wrapper and reduce JVM overhead.
I remembered that Tomcat had different class loaders for each web
application and have successfully been able to load two different wrappers
from two applications. However, I cannot load the native library in the
two classloaders. I understand this is JVM limitation. I do wonder, however,
if I can load the library in a parent class loader? I have tried this but I
am getting UnsatisfiedLinkError when the native methods are called.
Is there any workaround for this? I see tomcat uses some native APR library
and I was wondering if you have found a workaround? I see towards the bottom
of this bug report, someone seems to have a hack regarding System.out.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4225434
That probably would not fly for me.
Thanks for your time,
Brock Noland
1. This is a question for the users@ list, not dev@, because it is not
about improving Tomcat, but about running your webapp.
2. Tomcat Native library is loaded by
org.apache.catalina.core.AprLifecycleListener
class, if it is present in server.xml. You can look at the sources,
but there is nothing special.
3. You must read this doc:
http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
In essence, you have to put your jar in ${catalina.base}\lib and at
the same time _remove_ it from your webapp. The result will be that it
will be loaded by the Common classloader.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Sharing Native Library from parent classloader?
On 08/09/2010 12:15 PM, Konstantin Kolinko wrote:
2010/8/7 Brock Nolandbro...@gmail.com:
1. This is a question for the users@ list, not dev@, because it is not
about improving Tomcat, but about running your webapp.
But it could be.
2. Tomcat Native library is loaded by
org.apache.catalina.core.AprLifecycleListener
class, if it is present in server.xml. You can look at the sources,
but there is nothing special.
3. You must read this doc:
http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
In essence, you have to put your jar in ${catalina.base}\lib and at
the same time _remove_ it from your webapp. The result will be that it
will be loaded by the Common classloader.
For a long time I'm trying to solve the upper problems.
It would break (well extend) the servlet spec if we offer
to webapps that we do that automatically for them.
That way user would just provide a standard .war telling
what part of the webapp should be loaded by parent class loader
(making that singleton for the server lifetime of course)
On redeployment those resources won't be redeployed
until the full server restart.
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
improvement for changed PID file handling in catalina.sh since 6.0.24
Hi, the PID file handling was changed in 6.0.24 in catalina.sh, which avoid the use of an initscript to start tomcat proper (e.g. on CentOS/RHEL5). catalina.sh is currently too strict regarding existing PID file and has imho a too lightweight check. Below is a patch which improves the PID file handling. It fixes 2 issues. Issue 1: tomcat won't start, if initscript has already created as root a PID file and changed permissions, that user tomcat would able to write it's PID into this file. Fix: check existing PID file whether it's non-empty and if yes, check, whether PID is stale Issue 2: catalina.sh unconditionally tries to remove the given PID file, not testing the case that it has no write access to the directory (e.g. /var/run). Fix: check before removing a PID file (because this needs write access to pid file directory, which is e.g. /var/run, were user tomcat has no write access) Pls. include this fix into upstream, thank you. Peter --- catalina.sh 2010-07-19 12:59:45.0 + +++ catalina.sh 2010-08-09 13:00:56.0 + @@ -311,9 +311,15 @@ elif [ $1 = start ] ; then if [ ! -z $CATALINA_PID ]; then -if [ -f $CATALINA_PID ]; then - echo PID file ($CATALINA_PID) found. Is Tomcat still running? Start aborted. - exit 1 +if [ -f $CATALINA_PID -a -s $CATALINA_PID ]; then + echo Non-empty PID file ($CATALINA_PID) found. Is Tomcat still running? + pid=`cat $CATALINA_PID` + if ps -p $pid /dev/null; then +echo Tomcat is probably still running with PID $pid! Start aborted. +exit 1 + else +echo Tomcat is no longer running (stale PID file). + fi fi fi @@ -393,7 +399,11 @@ while [ $SLEEP -ge 0 ]; do kill -0 `cat $CATALINA_PID` /dev/null 21 if [ $? -gt 0 ]; then - rm $CATALINA_PID + if [ -w `dirname $CATALINA_PID` ]; then +rm $CATALINA_PID + else +echo Non-removable PID file found ($CATALINA_PID). + fi break fi if [ $SLEEP -gt 0 ]; then @@ -416,7 +426,11 @@ if [ -f $CATALINA_PID ]; then echo Killing: `cat $CATALINA_PID` kill -9 `cat $CATALINA_PID` -rm $CATALINA_PID +if [ -w `dirname $CATALINA_PID` ]; then + rm $CATALINA_PID +else + echo Non-removable PID file found ($CATALINA_PID). +fi fi fi fi - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49721] Fail to access the resources such as jsp files from a jar file which is supported by servlet 3.0
https://issues.apache.org/bugzilla/show_bug.cgi?id=49721 --- Comment #2 from Larry Isaacs larry.isa...@sas.com 2010-08-09 09:48:40 EDT --- Hi Konstantin, During my work on the Tomcat support in Eclipse Web Tools, the only requirement I found in the Servlet 3.0 spec for static resources in a jar was that they be found under META-INF/resources in the jar. I didn't see any requirement that the jar be a web-fragment. Wang, Since this behavior is only defined for Servlet 3.0 web applications, if your project has a web.xml, make sure it is a Servlet 3.0 web.xml in addition to making sure the JSP is in the META-INF/resources folder of the jar. A quick test shows this working for me for Tomcat 7.0.0 and 7.0.2 (currently under vote). Cheers, Larry -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49728] New: catalina.sh PID file handling not working if started by initscript
https://issues.apache.org/bugzilla/show_bug.cgi?id=49728 Summary: catalina.sh PID file handling not working if started by initscript Product: Tomcat 6 Version: 6.0.29 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: p...@bieringer.de the PID file handling was changed in 6.0.24 in catalina.sh, which avoid the use of an initscript to start tomcat proper (e.g. on CentOS/RHEL5). catalina.sh is currently too strict regarding existing PID file and has imho a too lightweight check. Below is a patch which improves the PID file handling. It fixes 2 issues. Issue 1: tomcat won't start, if initscript has already created as root a PID file and changed permissions, that user tomcat would able to write it's PID into this file. Fix: check existing PID file whether it's non-empty and if yes, check, whether PID is stale Issue 2: catalina.sh unconditionally tries to remove the given PID file, not testing the case that it has no write access to the directory (e.g. /var/run). Fix: check before removing a PID file (because this needs write access to pid file directory, which is e.g. /var/run, were user tomcat has no write access) Pls. include this fix into upstream, thank you. Peter --- catalina.sh 2010-07-19 12:59:45.0 + +++ catalina.sh 2010-08-09 13:00:56.0 + @@ -311,9 +311,15 @@ elif [ $1 = start ] ; then if [ ! -z $CATALINA_PID ]; then -if [ -f $CATALINA_PID ]; then - echo PID file ($CATALINA_PID) found. Is Tomcat still running? Start aborted. - exit 1 +if [ -f $CATALINA_PID -a -s $CATALINA_PID ]; then + echo Non-empty PID file ($CATALINA_PID) found. Is Tomcat still running? + pid=`cat $CATALINA_PID` + if ps -p $pid /dev/null; then +echo Tomcat is probably still running with PID $pid! Start aborted. +exit 1 + else +echo Tomcat is no longer running (stale PID file). + fi fi fi @@ -393,7 +399,11 @@ while [ $SLEEP -ge 0 ]; do kill -0 `cat $CATALINA_PID` /dev/null 21 if [ $? -gt 0 ]; then - rm $CATALINA_PID + if [ -w `dirname $CATALINA_PID` ]; then +rm $CATALINA_PID + else +echo Non-removable PID file found ($CATALINA_PID). + fi break fi if [ $SLEEP -gt 0 ]; then @@ -416,7 +426,11 @@ if [ -f $CATALINA_PID ]; then echo Killing: `cat $CATALINA_PID` kill -9 `cat $CATALINA_PID` -rm $CATALINA_PID +if [ -w `dirname $CATALINA_PID` ]; then + rm $CATALINA_PID +else + echo Non-removable PID file found ($CATALINA_PID). +fi fi fi fi -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49730] Race condition in StandardThreadExecutor : requests are sometimes enqueued instead of creating new threads
https://issues.apache.org/bugzilla/show_bug.cgi?id=49730 --- Comment #1 from sylvain.laur...@gmail.com 2010-08-09 16:38:11 EDT --- Created an attachment (id=25865) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25865) Patch for Tomcat 6 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49730] Race condition in StandardThreadExecutor : requests are sometimes enqueued instead of creating new threads
https://issues.apache.org/bugzilla/show_bug.cgi?id=49730 --- Comment #2 from sylvain.laur...@gmail.com 2010-08-09 16:38:47 EDT --- Created an attachment (id=25866) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25866) Patch for tomcat 7 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49730] Race condition in StandardThreadExecutor : requests are sometimes enqueued instead of creating new threads
https://issues.apache.org/bugzilla/show_bug.cgi?id=49730 sylvain.laur...@gmail.com changed: What|Removed |Added OS/Version||All --- Comment #3 from sylvain.laur...@gmail.com 2010-08-09 16:43:00 EDT --- the proposed patch for tc6 tries to modify as few things as possible. It would be cleaner to backport some stuff from tc7, but I don't know if we have to keep tc6 interface compatible with previous releases. Example : in tc7 TaskQueue is now a public class where it was an inner class of StandardThreadExecutor in tc6... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.2
Hopefully better late than never:
+1
On Aug 5, 2010, at 5:09 PM, Jason Brittain wrote:
Hi all!
[X] Beta - go ahead and release as 7.0.2 Beta
It seems very close to stable, to me.
One thing I noticed while testing 7.0.2 is that the WebModule MBean
ObjectNames differ slightly from those of Tomcat 6. Example:
Tomcat 7.0.2, ObjectName for the context /:
Catalina:j2eeType=WebModule,name=localhost/,J2EEApplication=none,J2EEServer=none
Tomcat 6.0.x, ObjectName for the context /:
Catalina:j2eeType=WebModule,name=//localhost/,J2EEApplication=none,J2EEServer=none
The diff is the two slashes in front of the hostname. I'm not sure why the
two slashes were there in the first place (I don't see it anywhere in JSR
77), nor if they served a purpose. Here's the code in Tomcat 6's
StandardContext (easy to find!) that built the string:
String name= // + ((hostName==null)? DEFAULT : hostName) +
((.equals(pathName))?/:pathName );
In Tomcat 7 it's in StandardWrapper (a little harder to find):
private String getWebModuleKeyProperties() {
StringBuilder keyProperties = new StringBuilder(,WebModule=);
String hostName = getParent().getParent().getName();
if (hostName == null) {
keyProperties.append(DEFAULT);
} else {
keyProperties.append(hostName);
}
...
I guess my question is: even if the slashes didn't serve any purpose, do we
want Tomcat 7's values to be consistent with those of Tomcat 6 for JMX API
compatibility reasons?
This was just one small inconsistency I noticed, versus Tomcat 6. I have
not checked other object name values nor attribute values versus those of
Tomcat 6.
Thanks.
--
Jason
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49721] Fail to access the resources such as jsp files from a jar file which is supported by servlet 3.0
https://issues.apache.org/bugzilla/show_bug.cgi?id=49721 --- Comment #3 from Wang Guangzhe rafaa.w...@gmail.com 2010-08-09 21:18:41 EDT --- (In reply to comment #2) Hi Konstantin, During my work on the Tomcat support in Eclipse Web Tools, the only requirement I found in the Servlet 3.0 spec for static resources in a jar was that they be found under META-INF/resources in the jar. I didn't see any requirement that the jar be a web-fragment. Wang, Since this behavior is only defined for Servlet 3.0 web applications, if your project has a web.xml, make sure it is a Servlet 3.0 web.xml in addition to making sure the JSP is in the META-INF/resources folder of the jar. A quick test shows this working for me for Tomcat 7.0.0 and 7.0.2 (currently under vote). Cheers, Larry Hi, Larry I also test an very simple case where there are only one jar file in the lib, it runs well. But when there are more than one jar files, it fails. I attach the two war files and please help to verify. Thanks! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49721] Fail to access the resources such as jsp files from a jar file which is supported by servlet 3.0
https://issues.apache.org/bugzilla/show_bug.cgi?id=49721 Wang Guangzhe rafaa.w...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49721] Fail to access the resources such as jsp files from a jar file which is supported by servlet 3.0
https://issues.apache.org/bugzilla/show_bug.cgi?id=49721 --- Comment #4 from Wang Guangzhe rafaa.w...@gmail.com 2010-08-09 21:21:21 EDT --- Created an attachment (id=25867) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25867) the war file with more than one jar files -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49721] Fail to access the resources such as jsp files from a jar file which is supported by servlet 3.0
https://issues.apache.org/bugzilla/show_bug.cgi?id=49721 --- Comment #5 from Wang Guangzhe rafaa.w...@gmail.com 2010-08-09 21:22:19 EDT --- Created an attachment (id=25868) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25868) the war file with only one jar file -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49234] JMX Descriptor Modifications
https://issues.apache.org/bugzilla/show_bug.cgi?id=49234 --- Comment #74 from chamith buddhika chamibuddh...@gmail.com 2010-08-10 00:22:51 EDT --- (In reply to comment #73) Created an attachment (id=25862) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25862) [details] o.a.Catalina.Core Operations Third Patch This patch adds to addChild method in ContainerMBean and does some adding and redorderings to the o.a.c.Core descriptor. - Start Tomcat - Via JMX, select the host - Create a new context addChild - Configure it to serve content (e.g. from an external directory) --- Other descriptor methods in StandardContext - Start it -- start/ startChild methods - Check the content is accessible -- Currently not sure how this can be done Any comment on this? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49732] New: reply_timeout can't wait forever.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49732
Summary: reply_timeout can't wait forever.
Product: Tomcat Connectors
Version: 1.2.30
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_jk
AssignedTo: dev@tomcat.apache.org
ReportedBy: yoshihara.ryu...@oss.ntt.co.jp
Created an attachment (id=25869)
-- (https://issues.apache.org/bugzilla/attachment.cgi?id=25869)
Log and configuration for this mod_jk's test
I tested following JSP file on the Tomcat.
%
try {
Thread.sleep(1);
} catch (Exception e) {}
%
html
headtitleTimeout/title/head
bodyTimeout/body
/html
workers.properties configuration was following:
worker.list=ap1
worker.template.type=ajp13
worker.template.port=8009
worker.template.lbfactor=1
worker.template.socket_timeout=5
worker.template.connect_timeout=3000
worker.template.prepost_timeout=3000
worker.template.recovery_options=3
worker.template.reply_timeout=0
worker.ap1.reference=worker.template
worker.ap1.host=127.0.0.1
worker.ap1.port=8009
***
For mod_jk 1.2.22, Apache access_log was followig after this test.
127.0.0.1 - - [05/Aug/2010:14:11:41 +0900] GET /ap001/timeout.jsp HTTP/1.1
200 73 11163952
For mod_jk 1.2.30, Apache access_log was followig after this test.
127.0.0.1 - - [05/Aug/2010:11:44:17 +0900] GET /ap001/timeout.jsp HTTP/1.1
502 306 7007548
Reference Guide say
http://tomcat.apache.org/connectors-doc/reference/workers.html
reply_timeout
By default (value zero) the webserver will wait forever which could be an
issue for you.
However, I guess mod_jk 1.2.30 does not wait for response forever.
I think influence of following fix.
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_connect.c?view=markuppathrev=705977
Best regards
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
