DO NOT REPLY [Bug 43684] New: - Connector uriworkermap dynamic reloading documentation mistake

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43684

   Summary: Connector uriworkermap dynamic reloading documentation
mistake
   Product: Tomcat 6
   Version: unspecified
  Platform: Other
   URL: http://tomcat.apache.org/connectors-
doc/reference/uriworkermap.html#Dynamic%20reloading
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The dynamic reloading section of the connector uriworkermap documentation at
http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html#Dynamic%20reloading
notes:

"For Apache you can configure the interval "n" using the directive JkMountFile,
for IIS you would use the attribute worker_mount_reload. The default value is 60
seconds. A value of "0" turns off the reloading."

The Apache directive name is incorrect; it should be JkMountFileReload as per
the Apache reference at
http://tomcat.apache.org/connectors-doc/reference/apache.html

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43683] - Accessing Servlet while Reloading context gives 404 error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43683





--- Additional Comments From [EMAIL PROTECTED]  2007-10-23 09:49 ---
Created an attachment (id=21026)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21026&action=view)
The Context file for the ServletRestartTest


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43683] - Accessing Servlet while Reloading context gives 404 error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43683





--- Additional Comments From [EMAIL PROTECTED]  2007-10-23 09:48 ---
This is how I envision the reload function working:

1) The servlet is happily handling GET/POST requests
2) reload is requested from the manager servlet
3) All new requests should be put into a queue, and wait to be serviced
4) If there are any 'currently active requests', tomcat should wait up to
StandardContext.unloadDelay seconds waiting for these requests to finish
5) Any requests that finish should be sent to the browser and finished up
6) When unloadDelay has been exceeded, or all currently active requests are
completed, destroy() should be called on the servlet
7) Wait until destroy() has finished
8) Clean up the context, and switch the classloader to the new classloader
9) If there are any requests in the queue, start the servlet, call
init(ServletConfig) on the servlet
10) wait for init(ServletConfig) to complete
11) All new requests should nolonger be put into queue, and should be serviced
by the servlet
12) All requests which are in queue, should now be released and processed
against the new servlet

Looking at the code in StandardContext, I can see this is probably what it
supposed to happen (it tries to pause incoming requests)... it just doesn't
quite work.  What we see is that if a request comes in while the servlet is
being destroyed, it will get a 404 from the servlet when the destroy() method
completes (EG: not right away!).  I looked at the code very reasonably
thoroughly in tomcat 5.5 (more thoroughly than I am looking at it right now) and
I seem to remember discovering that it was the start() context method that was
actually destroying the waiting request.  But I can't vouch for that, it was
probably a year ago :)  

It is worth noting that if you send in a SECOND request while the servlet is
being destroyed, that request *IS* handled properly... However... you can't send
that second request in TOO quickly after the first.  If they all come in at the
same time (see the apache bench testcase), they will *all* fail.  However even
if you're doing it reasonably quickly from firefox, the second request will come
through correctly.  I should also note that we had a patch for tomcat 4.1 which
made the reload() function work the way described above (it was a rather minor
change), however the patch is useless against tomcat 5 and greater, since the
start/stop code has been rewritten.  


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43683] - Accessing Servlet while Reloading context gives 404 error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43683





--- Additional Comments From [EMAIL PROTECTED]  2007-10-23 09:45 ---
Created an attachment (id=21025)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21025&action=view)
The ServletRestartTest file you need to extract


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43683] - Accessing Servlet while Reloading context gives 404 error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43683





--- Additional Comments From [EMAIL PROTECTED]  2007-10-23 09:44 ---
Attached is a context file and a test servlet.  This servlet has alot of sleeps,
and prints a bunch of debug which will make it clear what is going on
when the servlet is being reloaded.  This problem is reproducible even without
any sleep statements in the servlet.

To setup the test do this:
extract the apache-tomcat 6.0.14 binary distro
cd conf
cd Catalina
mkdir localhost
cd localhost
cp ../../../webapps/host-manager/manager.xml .  (This sets up the manager
servlet for you)
Drop the ServletRestartTest.xml into this directory
cd ../..
edit the tomcat-users.xml and paste in: (this lets you access the manager
servlet with username tomcat password tomcat)


cd ../webapps
extract the war file
cd ../bin
./catalina.sh run (this runs tomcat printing the stdio to the console)


To reproduce with this test case:
1. Visit this URL: http://localhost:8080/ServletRestartTest/ServletRestartTest
   You should get:
ServletRestartTest - Servlet is in the RUNNING state
2. Visit this URL: http://localhost:8080/manager/reload?path=/ServletRestartTest
3. Then immediately reload the original url
(http://localhost:8080/ServletRestartTest/ServletRestartTest)
4. You will then receive the 404 error approximately 5 seconds later:

HTTP Status 404 - Servlet ServletRestartTest is not available

type Status report

message Servlet ServletRestartTest is not available

description The requested resource (Servlet ServletRestartTest is not available)
is not available.
Apache Tomcat/6.0.14



Optionally you may use the apachebench program to see that you will get many
404s, depending on how many requests come in:
Replace step 3 with: ab -c 10 -n 10
http://localhost:8080/ServletRestartTest/ServletRestartTest
You will see that all 10 requests fail with non-200 responses:

This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient).done


Server Software:Apache-Coyote/1.1
Server Hostname:localhost
Server Port:8080

Document Path:  /ServletRestartTest/ServletRestartTest
Document Length:1081 bytes

Concurrency Level:  10
Time taken for tests:   5.49371 seconds
Complete requests:  10
Failed requests:0
Write errors:   0
Non-2xx responses:  10
Total transferred:  12850 bytes
HTML transferred:   10810 bytes
Requests per second:1.98 [#/sec] (mean)
Time per request:   5049.371 [ms] (mean)
Time per request:   504.937 [ms] (mean, across all concurrent requests)
Transfer rate:  2.38 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   0.3  0   1
Processing:  5026 5043   6.4   50455048
Waiting: 5026 5038   8.0   50385048
Total:   5027 5043   6.1   50455048

Percentage of the requests served within a certain time (ms)
  50%   5045
  66%   5045
  75%   5046
  80%   5048
  90%   5048
  95%   5048
  98%   5048
  99%   5048
 100%   5048 (longest request)



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43683] New: - Accessing Servlet while Reloading context gives 404 error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43683

   Summary: Accessing Servlet while Reloading context gives 404
error
   Product: Tomcat 6
   Version: 6.0.14
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If a servlet has finished it's init(ServletConfig), and is now ready to handle
requests, if you tell the tomcat manager to reload the context containing that
servlet (EG: w3m http://localhost:8080/manager/reload?path=/ServletRestartTest),
and you access that servlet via GET or POST (EG: w3m
http://localhost:8080/ServletRestartTest/ServletRestartTest) while the destroy()
method on the servlet is still executing, the GET or POST request will fail with
a 404 error after the destroy() method has been completed.  This is always
reproducible with my attached test case.  I believe this may be the root cause
of the issue described in #42518 which is described as an "Intermittent 404". 
With this test case, it is always reproducible, and not intermittent.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r587540 - /tomcat/tc6.0.x/trunk/STATUS

[remm]

Author: remm
Date: Tue Oct 23 08:28:09 2007
New Revision: 587540

URL: http://svn.apache.org/viewvc?rev=587540&view=rev
Log:
- Some votes, after getting a headache reviewing a patch.

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=587540&r1=587539&r2=587540&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Tue Oct 23 08:28:09 2007
@@ -39,8 +39,8 @@
 
 * Fix problem on a Forward when the outer most wrapper isn't a 
HttpServletRequest/ResponseWrapper.
   http://issues.apache.org/bugzilla/show_bug.cgi?id=43668
-  +1: billbarker
-  -1: remm (I don't feel comfortable including this sort of fix right before a 
release)
+  +1: billbarker, remm
+  -1: 
 
 * Tests for unit tests for the cookie issues. 
http://people.apache.org/~jfclere/patches/CookiesTest.patch
   +1: fhanik
@@ -48,9 +48,9 @@
 
 * Guess java location from the PATH environment. 
http://people.apache.org/~jfclere/patches/setclasspath.sh.patch
   And improve fix for 37284.
-  +1: fhanik
+  +1: fhanik, remm
   -1:
 
 * Harmonize with HTTP java.io code. Otherwise the socket is not closed. 
http://people.apache.org/~jfclere/patches/AjpPro.patch
-  +1: jfclere, fhanik
+  +1: jfclere, fhanik, remm
   -1:



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r587535 - /tomcat/tc6.0.x/trunk/STATUS

[fhanik]

Author: fhanik
Date: Tue Oct 23 08:10:05 2007
New Revision: 587535

URL: http://svn.apache.org/viewvc?rev=587535&view=rev
Log:
vote

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=587535&r1=587534&r2=587535&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Tue Oct 23 08:10:05 2007
@@ -48,7 +48,7 @@
 
 * Guess java location from the PATH environment. 
http://people.apache.org/~jfclere/patches/setclasspath.sh.patch
   And improve fix for 37284.
-  +1:
+  +1: fhanik
   -1:
 
 * Harmonize with HTTP java.io code. Otherwise the socket is not closed. 
http://people.apache.org/~jfclere/patches/AjpPro.patch



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Measuring bytes sent and received from and to Tomcat

[Dave Rathnow]

For our application, it's not that complicated.  All we need to know is
the number of bytes sent and received over the wire. We aren't using
SSL, redirects, etc.  
 

-Original Message-
From: Johnny Kewl [mailto:[EMAIL PROTECTED] 
Sent: October 22, 2007 11:26 PM
To: Tomcat Developers List
Subject: Re: Measuring bytes sent and received from and to Tomcat



---
HARBOR: http://coolharbor.100free.com/index.htm
Now Tomcat is also a cool application server

---
- Original Message -
From: "Dave Rathnow" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Monday, October 22, 2007 10:00 PM
Subject: Measuring bytes sent and received from and to Tomcat

=
Hi there, interesting question, more I think about it, more complicated
it gets ;)

Dont think its easy from TC, its too sophisticated, compression, SSL,
redirects, dispatches, clustering... think its hard to get a true
network measurement.

I would plunder something like TCPMon
https://tcpmon.dev.java.net/source/browse/tcpmon/
Its a NB plugin so can play with it first

Its really just a (bind - client) ie port 8080 to 8081 type idea - so
its easy to install, and easy to setup across multiple sites, clusters
etc etc.

Steal this (relay or tunnel) code and just mod it... I think you will be
able to modify it for client IP's cookies, special headers... anything
and then call it from a browser and get client billing breakdowns 
maybe...

==
We have an application that collects data from, and sends data to,
remote embedded devices.  Traditionally we have used TCP and UDP to send
and receive data over satellite.  The latest release of our product will
be using other communication medium with our devices making HTTP request
to our application that is running under JBoss/Tomcat.

The way we bill our clients is by charging them a usage fee based on the
number of bytes being sent over the air/wire.  Because of this, we need
to have a accurate count of the number of bytes sent and received from
each site, which is uniquely identified by it's IP address.  Using
either UDP and TCP this is simple as we are in control of the end
socket.

Is there a way we can do the same thing with Tomcat?  It's simple for us
to measure the number of byte in the payload of the HTTP
request/response, however that isn't enough.  We need to know the total
number of bytes being sent and received for each HTTP request.

Can someone suggest a way I could get an accurate count of these bytes?

Thanks,
Dave.

-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r587527 - /tomcat/tc6.0.x/trunk/STATUS

[fhanik]

Author: fhanik
Date: Tue Oct 23 07:52:36 2007
New Revision: 587527

URL: http://svn.apache.org/viewvc?rev=587527&view=rev
Log:
votes

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=587527&r1=587526&r2=587527&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Tue Oct 23 07:52:36 2007
@@ -43,7 +43,7 @@
   -1: remm (I don't feel comfortable including this sort of fix right before a 
release)
 
 * Tests for unit tests for the cookie issues. 
http://people.apache.org/~jfclere/patches/CookiesTest.patch
-  +1:
+  +1: fhanik
   -1:
 
 * Guess java location from the PATH environment. 
http://people.apache.org/~jfclere/patches/setclasspath.sh.patch
@@ -52,5 +52,5 @@
   -1:
 
 * Harmonize with HTTP java.io code. Otherwise the socket is not closed. 
http://people.apache.org/~jfclere/patches/AjpPro.patch
-  +1: jfclere
+  +1: jfclere, fhanik
   -1:



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43682] New: - JULI: web-inf/classes/logging.properties to support ${context} tag

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43682

   Summary: JULI: web-inf/classes/logging.properties to support
${context}  tag
   Product: Tomcat 6
   Version: 6.0.14
  Platform: Other
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


It would be a good to have "${context}" placeholder variable in JULI
logging.properties file. We could use it in a ".prefix" attribute to dynamically
use webapp's name as a file prefix.

Then if we have a web application, that can be installed 1...n copies to a same
Tomcat, we could use it out-of-the-box and each having separate log files.

  com.outerrim.catalina.logger.FileHandler.prefix = ${context}.


As it stands today, we must duplicate the webappname in a logging properties.

webapps/mywebapp/WEB-INF/classes/logging.properties
  handlers = com.outerrim.catalina.logger.FileHandler
  com.outerrim.catalina.logger.FileHandler.directory = ${catalina.base}/logs
  com.outerrim.catalina.logger.FileHandler.prefix = mywebapp.

webapps/my2ndwebapp/WEB-INF/classes/logging.properties
  handlers = com.outerrim.catalina.logger.FileHandler
  com.outerrim.catalina.logger.FileHandler.directory = ${catalina.base}/logs  
  com.outerrim.catalina.logger.FileHandler.prefix = my2ndwebapp.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 40002] - JULI Should Use Context ClassLoader for Formatter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40002





--- Additional Comments From [EMAIL PROTECTED]  2007-10-23 06:57 ---
I had a same need to override formatter. I wanted to have Tomcat4.0/Tomcat5.0x
type of logfile formatter. I created a formatter and copied .jar file to
tomcat/common/lib folder. It would be a lot more flexible able to use it from
web-inf/lib files.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PROPOSAL] - Catalina Ant JMX?

[Paul Shemansky]

While browsing the project, I noticed that there is an unused
separation of Catalina Ant JMX resources.  If this was unintended, a
possible cleanup patch is attached.
Index: java/org/apache/catalina/ant/jmx/JMXAccessorEqualsCondition.java
===
--- java/org/apache/catalina/ant/jmx/JMXAccessorEqualsCondition.java
(revision 587502)
+++ java/org/apache/catalina/ant/jmx/JMXAccessorEqualsCondition.java
(working copy)
@@ -34,7 +34,6 @@
  *   
  *   
  *   
- *   
  *   
  *   
  *
Index: java/org/apache/catalina/ant/jmx/JMXAccessorCondition.java
===
--- java/org/apache/catalina/ant/jmx/JMXAccessorCondition.java  (revision 
587502)
+++ java/org/apache/catalina/ant/jmx/JMXAccessorCondition.java  (working copy)
@@ -34,7 +34,6 @@
  *   
  *   
  *   
- *   
  *   
  *   
  *
Index: build.xml
===
--- build.xml   (revision 587502)
+++ build.xml   (working copy)
@@ -63,7 +63,6 @@
   
   
   
-  
   
 
   
Index: dist.xml
===
--- dist.xml(revision 587502)
+++ dist.xml(working copy)
@@ -66,7 +66,6 @@
   
   
   
-  
   
 
   
Index: extras.xml
===
--- extras.xml  (revision 587502)
+++ extras.xml  (working copy)
@@ -63,7 +63,6 @@
   
   
   
-  
   
 
   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r587478 - /tomcat/tc6.0.x/trunk/STATUS

[jfclere]

Author: jfclere
Date: Tue Oct 23 05:37:06 2007
New Revision: 587478

URL: http://svn.apache.org/viewvc?rev=587478&view=rev
Log:
Add a fix for sockets in CLOSE_WAIT state.

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=587478&r1=587477&r2=587478&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Tue Oct 23 05:37:06 2007
@@ -50,3 +50,7 @@
   And improve fix for 37284.
   +1:
   -1:
+
+* Harmonize with HTTP java.io code. Otherwise the socket is not closed. 
http://people.apache.org/~jfclere/patches/AjpPro.patch
+  +1: jfclere
+  -1:



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk 1.2.25, JkEnvVar evaluated too many times

[Ian Ward Comfort]

On Oct 22, 2007, at 11:24 PM, Mladen Turk wrote:
By adding some additional instrumentation to the code, I can see  
that each AJP packet is constructed with ((1 + 17) * 13) = 234  
envvar attributes -- the whole set of attributes is appended 18  
times in succession.  (Often this overflows the default maximum  
packet size.)


Can you use JkLogLevel debug and attach the packet dumps as well as  
the the config?


Sure.  For a little more information, I first applied a small patch  
to the 1.2.25 source [1].  For simplicity's sake I used a stripped- 
down Apache configuration with 3 VirtualHosts and a single JK worker  
[2] [3].  I've posted the resulting log output [4] and tcpdump output  
[5] generated with 'tcpdump -i lo -s 0 -w ajp.dump tcp port 8009'.


[1] http://rescomp.stanford.edu/~icomfort/jk/logging.patch
[2] http://rescomp.stanford.edu/~icomfort/jk/httpd.conf
[3] http://rescomp.stanford.edu/~icomfort/jk/workers.properties
[4] http://rescomp.stanford.edu/~icomfort/jk/mod_jk_log
[5] http://rescomp.stanford.edu/~icomfort/jk/ajp.dump

I get similar results with my fully-configured Apache 2.2.6 server.

Let me know if I can provide any more information.

--
Ian Ward Comfort <[EMAIL PROTECTED]>
System Administrator, Student Computing, Stanford University


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43675] - Classloader leak in org.apache.tomcat.util.http.ServerCookie

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43675





--- Additional Comments From [EMAIL PROTECTED]  2007-10-23 01:51 ---
Same problem with org.apache.jasper.xmlparser.ParserUtils.errorHandler and 
org.apache.jasper.xmlparser.ParserUtils.entityResolver.

Static reference from org.apache.jasper.xmlparser.ParserUtils.errorHandler 
(from class org.apache.jasper.xmlparser.ParserUtils) :
--> [EMAIL PROTECTED] (12 bytes) (field 
log:)
--> [EMAIL PROTECTED] (16 bytes) (??:)
--> class org.apache.commons.logging.impl.Log4JLogger (84 bytes) (??:)
--> [EMAIL PROTECTED] (152 bytes)
Static reference from org.apache.jasper.xmlparser.ParserUtils.entityResolver 
(from class org.apache.jasper.xmlparser.ParserUtils) :
--> [EMAIL PROTECTED] (12 bytes) (field 
log:)
--> [EMAIL PROTECTED] (16 bytes) (??:)
--> class org.apache.commons.logging.impl.Log4JLogger (84 bytes) (??:)
--> [EMAIL PROTECTED] (152 bytes) 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43675] New: - Classloader leak in org.apache.tomcat.util.http.ServerCookie

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43675

   Summary: Classloader leak in
org.apache.tomcat.util.http.ServerCookie
   Product: Tomcat 5
   Version: 5.5.24
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm investigating problems related to PermGen saturation on hot redeploy of my 
web applications. Using jhat I found that the class 
org.apache.catalina.util.http.ServerCookie has a static reference to my webapp 
classloader through the log field. This is what jhat shows:

Static reference from org.apache.tomcat.util.http.ServerCookie.log (from class 
org.apache.tomcat.util.http.ServerCookie) :
--> [EMAIL PROTECTED] (16 bytes) (??:)
--> class org.apache.commons.logging.impl.Log4JLogger (84 bytes) (??:)
--> [EMAIL PROTECTED] (152 bytes) 

It is similar to bug#42172.

The problem shows in Tomcat 5.5.25

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]