Re: [g...@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed

2010-08-09 Thread Stefan Bodewig
On 2010-08-09, Bill Barker wrote:

> From: "Stefan Bodewig" 

>> this is due to a configuration error in Gump that I caused - fixed now.

> I can't find the fix on the Gump list,



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

2010-08-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=49721

Konstantin Kolinko  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #1 from Konstantin Kolinko  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-08-09 Thread Konstantin Kolinko
2010/8/7 Brock Noland :
> 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?

2010-08-09 Thread Mladen Turk

On 08/09/2010 12:15 PM, Konstantin Kolinko wrote:

2010/8/7 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.



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

2010-08-09 Thread Peter Bieringer
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 2>&1
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

2010-08-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=49721

--- Comment #2 from Larry Isaacs  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

2010-08-09 Thread bugzilla
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 2>&1
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] New: Race condition in StandardThreadExecutor : requests are sometimes enqueued instead of creating new threads

2010-08-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=49730

   Summary: Race condition in StandardThreadExecutor : requests
are sometimes enqueued instead of creating new threads
   Product: Tomcat 6
   Version: 6.0.29
  Platform: Macintosh
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: sylvain.laur...@gmail.com


In tomcat 6, I often configure an Executor with minSpareThreads=0 to work
around memory leak issues upon redeployment.

Sometimes (especially in development), when I refresh a page of my webapp with
Safari, Chrome or Firefox, some resources of the page take several seconds
(>10s) to be served though they are static resources and should come in less
than 50ms. For instance, over 15 requests for a page (1 for html, the others
for resources like js, css, images...), I sometimes have 1 or 2 that take >10s. 

After analysis, I found that in
org.apache.catalina.core.StandardThreadExecutor.TaskQueue.offer(Runnable) the
statement 
if (parent.getActiveCount()<(parent.getPoolSize()))
is sometimes true unexpectedly. Here is the scenario :

- ThreadPoolExecutor is empty
- the user refreshes the page (or accesses it with an empty cache) in his web
browser for a page that uses a more than 10-15 resources
- the browser establishes one TCP connection and a new Thread is created
- after the browser receives the response, it decides to load as many resources
as possible in parallel. For this it establishes up to 6 TCP connections (in my
tests)
- The Acceptor thread calls StandardThreadExecutor.execute to process each
incoming connection.
- For each call, StandardThreadExecutor.TaskQueue.offer(Runnable) is being
called
- if you study the sources of Java 6 ThreadPoolExecutor, you can see that
there's a small delay between the time a new Thread is created (thus increasing
poolSize) and the time it starts working on its first task (increasing the
activeCount)
- Since in my case connections are established in a rapid burst, the calls to
TaskQueue.offer() are sometimes faster than this small delay, so that we do
have parent.getActiveCount()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

2010-08-09 Thread bugzilla
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

2010-08-09 Thread bugzilla
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

2010-08-09 Thread bugzilla
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

2010-08-09 Thread Jim Jagielski
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

2010-08-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=49721

--- Comment #3 from Wang Guangzhe  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

2010-08-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=49721

Wang Guangzhe  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

2010-08-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=49721

--- Comment #4 from Wang Guangzhe  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

2010-08-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=49721

--- Comment #5 from Wang Guangzhe  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

2010-08-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=49234

--- Comment #74 from chamith buddhika  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.

2010-08-09 Thread bugzilla
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) {}
%>

Timeout
Timeout



 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=markup&pathrev=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