DO NOT REPLY [Bug 40960] - Timeout when reading from underlying socket does throw IOException with APR and SocketTimeoutException without APR

[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=40960


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows 2000|All
Version|5.5.23  |5.5.22




--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 00:15 ---
In the description it is told as the issue is there in 5.5.23,but in the
changelog of tomcat 5.5 it is been told that from the version 5.5.10 this issue
is fixed.

"Fix NPE when POST size exceeds limit defined by maxPostSize. (markt)".

Can anyone help me that what i refering is correct or not

(In reply to comment #0)
> Timeout when reading from underlying socket does throw IOException with APR 
> and
> SocketTimeoutException without APR.
> This difference causes servlet code handling "timeout exceptions" to break 
> (and
> not be fixeable) if APR is used.
> In class "org.apache.coyote.http11.InternalAprInputBuffer" for method "boolean
> fill() throws IOException":
> (in block if (!parsingHeader) ) The return code for Socket.recvbb  is not
> checked for Status.ETIMEDOUT or Status.TIMEUP, therefore an IOException is
> thrown whatever the reason for the exception.  This is a behavior change from
> non-APR HTTP 1.1 connector.
> 
> The following new code for the fill method fixes the issue:
>/**
>  * Fill the internal buffer using data from the undelying input stream.
>  *
>  * @return false if at end of stream
>  */
> protected boolean fill()
> throws IOException {
> 
> int nRead = 0;
> 
> if (parsingHeader) {
> 
> if (lastValid == buf.length) {
> throw new IOException
> (sm.getString("iib.requestheadertoolarge.error"));
> }
> 
> bbuf.clear();
> nRead = Socket.recvbb
> (socket, 0, buf.length - lastValid);
> if (nRead > 0) {
> bbuf.limit(nRead);
> bbuf.get(buf, pos, nRead);
> lastValid = pos + nRead;
> } else {
> if ((-nRead) == Status.EAGAIN) {
> return false;
> } else {
> throw new IOException(sm.getString("iib.failedread"));
> }
> }
> 
> } else {
> 
> buf = bodyBuffer;
> pos = 0;
> lastValid = 0;
> bbuf.clear();
> nRead = Socket.recvbb
> (socket, 0, buf.length);
> if (nRead > 0) {
> bbuf.limit(nRead);
> bbuf.get(buf, 0, nRead);
> lastValid = nRead;
> } else {
> // CP: Start change
>   if ((-nRead) == Status.ETIMEDOUT || (-nRead) == Status.TIMEUP) {
>   throw new 
> java.net.SocketTimeoutException(sm.getString("iib.failedread"));
>   } else {
>   throw new IOException(sm.getString("iib.failedread"));
>   }
> // CP: End change
> }
> 
> }
> 
> return (nRead > 0);
> 
> }
> 
> Since SocketTimeOutException is also an IOException, this modification cannot
> break code that does not filter timeout exceptions.



-- 
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]

[RESULT][VOTE] Releasing Tomcat Connectors 1.2.24

[Rainer Jung]

We received six stable votes (Henri, Yoav, Mladen, Peter, Günter and me) 
and no other votes.


I'm now starting to publish the release.

Thanks for supporting this release.

Regards,

Rainer

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

svn commit: r561260 - in /tomcat/site/trunk: docs/download-connectors.html xdocs/download-connectors.xml

[rjung]

Author: rjung
Date: Tue Jul 31 01:16:17 2007
New Revision: 561260

URL: http://svn.apache.org/viewvc?view=rev&rev=561260
Log:
Updating connectors-download page for new 1.2.24 release.

Modified:
tomcat/site/trunk/docs/download-connectors.html
tomcat/site/trunk/xdocs/download-connectors.xml

Modified: tomcat/site/trunk/docs/download-connectors.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/download-connectors.html?view=diff&rev=561260&r1=561259&r2=561260
==
--- tomcat/site/trunk/docs/download-connectors.html (original)
+++ tomcat/site/trunk/docs/download-connectors.html Tue Jul 31 01:16:17 2007
@@ -236,18 +236,18 @@
 
 
 
-JK
 1.2.23 Source Release tar.gz (e.g. Unix, Linux, Mac OS)
+JK
 1.2.24 Source Release tar.gz (e.g. Unix, Linux, Mac OS)
 
 
-[http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.tar.gz.asc";>pgp]
+[http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.tar.gz.asc";>pgp]
 
 
 
 
-JK
 1.2.23 Source Release zip (e.g. Windows)
+JK
 1.2.24 Source Release zip (e.g. Windows)
 
 
-[http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.zip.asc";>pgp]
+[http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.zip.asc";>pgp]
 
 
 

Modified: tomcat/site/trunk/xdocs/download-connectors.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/download-connectors.xml?view=diff&rev=561260&r1=561259&r2=561260
==
--- tomcat/site/trunk/xdocs/download-connectors.xml (original)
+++ tomcat/site/trunk/xdocs/download-connectors.xml Tue Jul 31 01:16:17 2007
@@ -30,13 +30,13 @@
 
 
 Source (please choose the 
correct format for your platform)
-JK
 1.2.23 Source Release tar.gz (e.g. Unix, Linux, Mac OS)
-[http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.tar.gz.asc";>pgp]
+JK
 1.2.24 Source Release tar.gz (e.g. Unix, Linux, Mac OS)
+[http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.tar.gz.asc";>pgp]
 
 
 
-JK
 1.2.23 Source Release zip (e.g. Windows)
-[http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.zip.asc";>pgp]
+JK
 1.2.24 Source Release zip (e.g. Windows)
+[http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.zip.asc";>pgp]
 
 
 



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

Possible bug regarding session timeouts in clustered tomcats

[Alexander Maas]

Hi,

we are using tomcat (6.0.13) in a clustered environment and have noticed
some inconsistent behavior regarding session timeouts.

Or setup is as follows:

Two machines, nodeA and nodeB, each configured identically:
  debian etch
  tomcat 6.0.13
  JDK 1.6.0_02
  apache 2.2.3
  mod_jk 1.2.23


The nodes are configured to replicate sessions via

   ...
   
   ...


There is no jvmRoute defined since we can't use sticky sessions because
the nodes are rotated via round-robin DNS.

The replication in itself works as expected, however we noticed that
some sessions took very long to expire or didn't expire at all.

After some digging and debugging we were able to track the problem to
the following cause:

1) User 1 visits the site and hits nodeA
2) Session 1 is created as primary on nodeA with a valid
maxInactiveInterval ("120" in out testing case)
It also gets replicated to nodeB but is created without
maxInactiveInterval (so the default of -1 is used)
3) User gets nodeB for his next request
4) Session 1 becomes primary on nodeB

Now we have the following situation:
Session 1 is valid on both nodes but on nodeB doesn't have a
maxInactiveInterval.
Now one of two things can happen:

1) The user again jumps nodes and goes back to nodeA thereby making the
session on nodeA primary again.
In this case everything is good. The session still has a valid
maxInactiveInterval and is expired once this timeout is hit.
2) The user stays on nodeB (or leaves the site).
This is where the problem occurs:
On nodeB the session has no maxInactiveInterval meaning it will never
expire.
nodeA OTOH still has a maxInactiveInterval but is not primary for
this session. So it will expire the session after
(2*maxInactiveInterval) but only locally because it assumes the
primary for this session to be dead.
Now we have a session that is "half" expired between the nodes.

We belive the problem originates in

org.apache.catalina.ha.session.DeltaManager
protected void handleSESSION_CREATED(SessionMessage msg,Member sender)

In line 1409 a new DeltaSession object is created via
createEmptySession() which - of course - inherits the default
maxInactiveInterval (-1) from org.apache.catalina.session.StandardSession.


The attached patch *SHOULD* fix this. (It's untested because I wasn't
able to convince ant to build successfully (for other reasons than this
patch)).


Alex.

--- 
apache-tomcat-6.0.13-src/java/org/apache/catalina/ha/session/DeltaManager.java  
2007-05-05 03:43:36.0 +0200
+++ 
apache-tomcat-6.0.13-src.session/java/org/apache/catalina/ha/session/DeltaManager.java
  2007-07-30 16:02:19.835388000 +0200
@@ -1411,6 +1411,8 @@
 session.setValid(true);
 session.setPrimarySession(false);
 session.setCreationTime(msg.getTimestamp());
+// use container maxInactiveInterval so that session will expire 
correctly in case of primary transfer
+session.setMaxInactiveInterval(getMaxInactiveInterval());
 session.access();
 if(notifySessionListenersOnReplication)
 session.setId(msg.getSessionID());


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

DO NOT REPLY [Bug 42996] - POST with nio connector results in missing variables

[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=42996





--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 02:31 ---
This looks exactly like what I saw with the NIO connector; POST parameters
sometimes went missing. It happened very infrequently, and when I tried to
produce an isolated test case (which I spent several hours on), I could not
reproduce it. Note that my requests in which this happened had POST params only
and no GET params.

When debugging in my application I saw behavior that I found suspect: the
parametersParsed flag on the Request was sometimes true even though the
parameters had not been parsed yet, causing all the POST params to not be parsed
and the parameters map to be empty. Unfortunately this problem happened so
infrequently that I only caught it in the debugger once, and was not able to
determine how this could come about.

The strange thing is, that the problem went away in my application (I don't know
what caused it to go away), and I have not seen it since. I figured it may have
been incorrect synchronization on my part...

Regards,
Sebastiaan

-- 
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]

[ANN] Apache Tomcat JK 1.2.24 Web Server Connector released

[Rainer Jung]

The Apache Tomcat team is pleased to announce the immediate availability
of version 1.2.24 of the Apache Tomcat Connectors.

It contains connectors, which allow a web server such as Apache HTTPD,
Microsoft IIS and Sun Web Server to act as a front end to the Tomcat web
application server.

This version contains several enhancements and fixes a number of minor
bugs of the previous version 1.2.23.

See http://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html
for a complete list of changes.

Source distribtions can be downloaded from an Apache Software Foundation 
mirror at:


http://tomcat.apache.org/download-connectors.cgi

Binary distributions for a number of different operating systems and
web servers can be downloaded from an Apache Software Foundation mirror at:

http://tomcat.apache.org/download-connectors.cgi

Documentation for using Apache Tomcat Connectors can be found at:

http://tomcat.apache.org/connectors-doc/

Thank you,

-- The Apache Tomcat Team





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

DO NOT REPLY [Bug 40960] - Timeout when reading from underlying socket does throw IOException with APR and SocketTimeoutException without APR

[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=40960





--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 04:37 ---
(In reply to comment #4)
> In the description it is told as the issue is there in 5.5.23,but in the
> changelog of tomcat 5.5 it is been told that from the version 5.5.10 this 
> issue
> is fixed.

You are mis-reading the changelog. This issue does not appear in the changelog
for 5.5.23.

> "Fix NPE when POST size exceeds limit defined by maxPostSize. (markt)".

The NPE fix has nothing to do with this bug.

The fix will be in 5.5.24 onwards.

-- 
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]

Re: [VOTE] Release build 6.0.14

[Filip Hanik - Dev Lists]

According to the release process, the 6.0.14 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[X] Stable

Filip



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

svn commit: r561326 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/session/DeltaManager.java

[fhanik]

Author: fhanik
Date: Tue Jul 31 06:35:35 2007
New Revision: 561326

URL: http://svn.apache.org/viewvc?view=rev&rev=561326
Log:
patch provided by Alexander Maas, fix timeout setting on a replicated session

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/session/DeltaManager.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/session/DeltaManager.java?view=diff&rev=561326&r1=561325&r2=561326
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/session/DeltaManager.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/session/DeltaManager.java 
Tue Jul 31 06:35:35 2007
@@ -1411,6 +1411,8 @@
 session.setValid(true);
 session.setPrimarySession(false);
 session.setCreationTime(msg.getTimestamp());
+// use container maxInactiveInterval so that session will expire 
correctly in case of primary transfer
+session.setMaxInactiveInterval(getMaxInactiveInterval());
 session.access();
 if(notifySessionListenersOnReplication)
 session.setId(msg.getSessionID());



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

Re: Possible bug regarding session timeouts in clustered tomcats

[Filip Hanik - Dev Lists]

thanks for the patch, it has bee applied

Filip

Alexander Maas wrote:

Hi,

we are using tomcat (6.0.13) in a clustered environment and have noticed
some inconsistent behavior regarding session timeouts.

Or setup is as follows:

Two machines, nodeA and nodeB, each configured identically:
  debian etch
  tomcat 6.0.13
  JDK 1.6.0_02
  apache 2.2.3
  mod_jk 1.2.23


The nodes are configured to replicate sessions via

   ...
   
   ...


There is no jvmRoute defined since we can't use sticky sessions because
the nodes are rotated via round-robin DNS.

The replication in itself works as expected, however we noticed that
some sessions took very long to expire or didn't expire at all.

After some digging and debugging we were able to track the problem to
the following cause:

1) User 1 visits the site and hits nodeA
2) Session 1 is created as primary on nodeA with a valid
maxInactiveInterval ("120" in out testing case)
It also gets replicated to nodeB but is created without
maxInactiveInterval (so the default of -1 is used)
3) User gets nodeB for his next request
4) Session 1 becomes primary on nodeB

Now we have the following situation:
Session 1 is valid on both nodes but on nodeB doesn't have a
maxInactiveInterval.
Now one of two things can happen:

1) The user again jumps nodes and goes back to nodeA thereby making the
session on nodeA primary again.
In this case everything is good. The session still has a valid
maxInactiveInterval and is expired once this timeout is hit.
2) The user stays on nodeB (or leaves the site).
This is where the problem occurs:
On nodeB the session has no maxInactiveInterval meaning it will never
expire.
nodeA OTOH still has a maxInactiveInterval but is not primary for
this session. So it will expire the session after
(2*maxInactiveInterval) but only locally because it assumes the
primary for this session to be dead.
Now we have a session that is "half" expired between the nodes.

We belive the problem originates in

org.apache.catalina.ha.session.DeltaManager
protected void handleSESSION_CREATED(SessionMessage msg,Member sender)

In line 1409 a new DeltaSession object is created via
createEmptySession() which - of course - inherits the default
maxInactiveInterval (-1) from 
org.apache.catalina.session.StandardSession.



The attached patch *SHOULD* fix this. (It's untested because I wasn't
able to convince ant to build successfully (for other reasons than this
patch)).


Alex.



--- 
apache-tomcat-6.0.13-src/java/org/apache/catalina/ha/session/DeltaManager.java  
2007-05-05 03:43:36.0 +0200
+++ 
apache-tomcat-6.0.13-src.session/java/org/apache/catalina/ha/session/DeltaManager.java
  2007-07-30 16:02:19.835388000 +0200
@@ -1411,6 +1411,8 @@
 session.setValid(true);
 session.setPrimarySession(false);
 session.setCreationTime(msg.getTimestamp());
+// use container maxInactiveInterval so that session will expire 
correctly in case of primary transfer
+session.setMaxInactiveInterval(getMaxInactiveInterval());
 session.access();
 if(notifySessionListenersOnReplication)
 session.setId(msg.getSessionID());


  



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


No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.476 / Virus Database: 269.11.0/927 - Release Date: 7/30/2007 5:02 PM
  



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

svn commit: r561328 - /tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java

[fhanik]

Author: fhanik
Date: Tue Jul 31 06:38:23 2007
New Revision: 561328

URL: http://svn.apache.org/viewvc?view=rev&rev=561328
Log:
forward port from 6.0

Modified:
tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java

Modified: tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java?view=diff&rev=561328&r1=561327&r2=561328
==
--- tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java Tue Jul 
31 06:38:23 2007
@@ -1411,6 +1411,8 @@
 session.setValid(true);
 session.setPrimarySession(false);
 session.setCreationTime(msg.getTimestamp());
+// use container maxInactiveInterval so that session will expire 
correctly in case of primary transfer
+session.setMaxInactiveInterval(getMaxInactiveInterval());
 session.access();
 if(notifySessionListenersOnReplication)
 session.setId(msg.getSessionID());



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

DO NOT REPLY [Bug 42996] - POST with nio connector results in missing variables

[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=42996





--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 06:42 ---
Hey guys,
please test with 6.0.14 or 6.x as there have been numerous bug fixes.
the 6.0.14 binaries can be found here:
http://people.apache.org/~remm/tomcat-6/v6.0.14/

Let me know what you come up with
Filip

-- 
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 43002] - NIO connector performance issue in 6.0.13

[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=43002


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 06:43 ---
There was a memory leak in 6.0.10 when using a dynamically sized thread pool.
The fix for this was to add a bounded pool of objects, and that will slow it
down a bit.
If you are up for it, please leave us your test case, with results from .10 and
.13 and I will see if there is anything else that happened.

thanks
Filip

-- 
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]

Re: [VOTE] Release build 6.0.14

[Yoav Shapira]

Hey,

On 7/30/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> The candidates binaries are available here:
> http://people.apache.org/~remm/tomcat-6/v6.0.14/
>
> According to the release process, the 6.0.14 tag is:
> [ ] Broken
> [ ] Alpha
> [ ] Beta
> [ X ] Stable

TCK?

Yoav

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

Re: [VOTE] Release build 6.0.14

[Tim Funk]

As long as http://issues.apache.org/bugzilla/show_bug.cgi?id=43002 is 
not serious then stable


-Tim

Remy Maucherat wrote:

The candidates binaries are available here:
http://people.apache.org/~remm/tomcat-6/v6.0.14/

According to the release process, the 6.0.14 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[X] Stable



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

Re: [VOTE] Release build 6.0.14

[Filip Hanik - Dev Lists]

Yoav Shapira wrote:

Hey,

On 7/30/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
  

The candidates binaries are available here:
http://people.apache.org/~remm/tomcat-6/v6.0.14/

According to the release process, the 6.0.14 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[ X ] Stable



TCK?
  

I ran them, all went fine
Filip

Yoav

-
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]

DO NOT REPLY [Bug 38897] - Invalid TLDs receive cryptic 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=38897


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
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 43002] - NIO connector performance issue in 6.0.13

[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=43002


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 09:04 ---
One thing I didn't mention is that I have 120 users configured in Grinder.   
The degradation was not small it was in excess of 50% making 6.0.13 unusable 
for us.   Also, under load EOFExceptions were occurring.   The application used 
for testing is quite ordinary and it would be difficult to provide.  I suspect 
that any one of the sample apps will work.

Steps to reproduce:
1) Set up a grinder test against a simple app like say the struts-mailreader.
2) Use JDK 1.6.0_01
3) Configure 120 concurrent users in Grinder.

Perform the tests on both 6.0.10 and 6.0.13.  Compare the requests/second 
throughput.

 

-- 
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 43002] - NIO connector performance issue in 6.0.13

[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=43002


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 10:15 ---
you need to provide more info, what are you testing, static files, size of the
files, JSP pages,
number of requests, sleeping between requests, etc

-- 
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 40668] - MailSessionFactory is missing in Tomcat 5.5.23

[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=40668





--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 10:39 ---
(In reply to comment #26)
> This has been fixed in the build script. You are now unable to complete a
> release package without these two jars in your classpath.
> The libraries were optional in the distribution, so if they were not present
> they wouldn't be included. Next major release will include this, in the
> meantime, the recommend work around is already mentioned here
> http://issues.apache.org/bugzilla/show_bug.cgi?id=40668#c2
> 
> Please note, it is safe to patch these two files, they have not changed since
5.5.17
> 
> Sorry for the inconvenience
> 

This still isn't fixed in the core binary distribution downloaded here:
http://tomcat.apache.org/download-55.cgi#5.5.23

-- 
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 43002] - NIO connector performance issue in 6.0.13

[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=43002


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 10:48 ---
The response payload is about ~10K with JSP's that call Java application code.  
Normal unladen execution times are about ~8ms.   The web pages include one or 
more images/flash applications.   The test client ignores these however.  There 
are NO SLEEPS between requests, as we are trying to similate normal traffic 
through our load balancing appliances.   I'm attaching the grinder config file 
and JPython test script.

Here is the grinder configuration file:

# grinder configuration

# Required fields #
PROJECT=RefAppLoadTest

#TEST_SCRIPT=ReferenceAppTest_S9_DualNic_noimages_random_nosleep.py
#TEST_SCRIPT=ReferenceAppTest_noimages_random_nosleep.py
TEST_SCRIPT=ReferenceAppTest_DefaultContext_Random_NoSleep.py
#TEST_SCRIPT=ReferenceAppTest_noimages_nosleep_spiking.py
#TEST_SCRIPT=ReferenceAppTest_DefaultContext_Random_20RPS_rhvm2-3-4.py
#TEST_SCRIPT=ReferenceAppTest_DefaultContext_Random_TestResults1field_5RPS.py

# Duration of the full test (minutes)
# This time must match the time required for the test script
# to run
TEST_DURATION=10
#TEST_RUNS=2

# The users will be evenly distributed across all clients,
# using the floor of NUM_USERS/LOAD_CLIENTS
LINUX_LOAD_CLIENTS=sedplatfc5,sedplatfc3,sedplatfc4
#LINUX_LOAD_CLIENTS=sedplatfc5
WIN_LOAD_CLIENTS=

# Total number of users across all load clients
NUM_USERS=120

# Number of users to start with each grouping
USERS_IN_GROUP=30

# Time in seconds between the start of each group of users
GROUP_RAMPUP_TIME=120

# Total number of spike users
SPIKE=0

# How long between spikes in seconds
SPIKE_INTERVAL=180

# Deviation around the spike in milliseconds
SPIKE_SIGMA=750

# The server to test
# Barista sedplat9
#TARGET_SERVER=sedplat9:9100

# Tomcat sedplat9
#TARGET_SERVER=sedplat9:9000

# Tomcat sedplat3
#TARGET_SERVER=sedplat3:9000
#TARGET_SERVER=sedplat4:9000

#Tomcat on Red Hat
#TARGET_SERVER=sedplatfc1:9000

#Tomcat on Red Hat Virtual
TARGET_SERVER=sedplat9.go.com:9000

#Stouted Ref App
#TARGET_SERVER=sedplat5

#Quantified Stouted Advarked Ref App
#TARGET_SERVER=sedplat8:8082

# The process to monitor on the server
#TARGET_PROCESS=DPReferenceAppB
TARGET_PROCESS=DPReferenceApp.
#TARGET_PROCESS=inetinfo

# The interval to retrieve performance data samples from the server (seconds)
SAMPLING_PERIOD=5



# Optional fields #
# Defaults to no perfmon logging
#PERFMON=true

# Defaults to true
USE_CONSOLE=true

Here is the Python script
=
# The Grinder 3.0-beta30
# HTTP script recorded by TCPProxy at Sep 28, 2006 3:16:38 PM
import random

from net.grinder.script import Test
from net.grinder.script.Grinder import grinder
from net.grinder.plugin.http import HTTPPluginControl, HTTPRequest
from HTTPClient import NVPair
connectionDefaults = HTTPPluginControl.getConnectionDefaults()
httpUtilities = HTTPPluginControl.getHTTPUtilities()

requestsPerSecond = 50

# To use a proxy server, uncomment the next line and set the host and port.
# connectionDefaults.setProxyServer("localhost", 8001)

# These definitions at the top level of the file are evaluated once,
# when the worker process is started.

connectionDefaults.defaultHeaders = \
  ( NVPair('User-Agent', 'Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 
rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7'),
NVPair('Accept-Encoding', 'gzip,deflate'),
NVPair('Accept-Language', 'en-us,en;q=0.5'),
NVPair('Accept-Charset', 'ISO-8859-1,utf-8;q=0.7,*;q=0.7'),
NVPair('INLINEREPLACE', 'Yes'), )

headers= \
  ( NVPair
('Accept', 'text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/
plain;q=0.8,image/png,*/*;q=0.5'),
NVPair
('Referer', 'http://sedplat9.go.com:9000/ReferenceApplication/ReferenceApplicati
on/dynamic/homePage'), )

url0 = 'http://sedplat9.go.com:9000'

articleIds = ['36', '113', '114', '115', '116', '117', '118', '119', '120', 
  '121', '122', '123', '124', '125', '126', '127', '128', '129', '13
0', '132', '622']

aboutIds = ['314','315','316','317','318', '319', '320', '321', '621']

# Create an HTTPRequest for each request, then replace the
# reference to the HTTPRequest with an instrumented version.
# You can access the unadorned instance using request101.__target__.
homePageRequest = HTTPRequest(url=url0, headers=headers)

Inlining dependencies

[David Blevins]

Hi Guys,

Really curious on what approach you used to inline all your 3rd party  
deps into org.apache.tomcat.util.  Curious if you took them as is, or  
trimmed them down to just what you need.  Were any tools used to  
help?  Any disadvantages that you have noticed other than having to  
port fixes on those libs in?


I've been wanting to do a similar thing in OpenEJB.  Any input is  
appreciated.


-David




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

Re: Inlining dependencies

[Yoav Shapira]

Hey,

On 7/31/07, David Blevins <[EMAIL PROTECTED]> wrote:
> Really curious on what approach you used to inline all your 3rd party
> deps into org.apache.tomcat.util.  Curious if you took them as is, or
> trimmed them down to just what you need.  Were any tools used to
> help?  Any disadvantages that you have noticed other than having to
> port fixes on those libs in?

IIRC we take a known version of a library and do a string replace on
package names, essentially.  It's all done in Ant tasks: look for how
the Tomcat build handles Jakarta Commons DBCP for example.  We don't
trim them down AFAIK, nor do we have to do any porting because we
re-grab the library (ideally from a known stable version) with every
release.

Yoav

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

Re: Inlining dependencies

[David Blevins]

On Jul 31, 2007, at 11:59 AM, Yoav Shapira wrote:


Hey,

On 7/31/07, David Blevins <[EMAIL PROTECTED]> wrote:

Really curious on what approach you used to inline all your 3rd party
deps into org.apache.tomcat.util.  Curious if you took them as is, or
trimmed them down to just what you need.  Were any tools used to
help?  Any disadvantages that you have noticed other than having to
port fixes on those libs in?


IIRC we take a known version of a library and do a string replace on
package names, essentially.  It's all done in Ant tasks: look for how
the Tomcat build handles Jakarta Commons DBCP for example.  We don't
trim them down AFAIK, nor do we have to do any porting because we
re-grab the library (ideally from a known stable version) with every
release.


That's really cool.  Thanks for the info.

I'm just very impressed with how clean the result is and there's the  
obvious benefit of those library versions not conflicting with any  
apps deployed without the need for fancy classloader scoping.


-David




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

Re: Inlining dependencies

[Yoav Shapira]

Hey,

On 7/31/07, David Blevins <[EMAIL PROTECTED]> wrote:
> > IIRC we take a known version of a library and do a string replace on
> > package names, essentially.  It's all done in Ant tasks: look for how
> > the Tomcat build handles Jakarta Commons DBCP for example.  We don't
> > trim them down AFAIK, nor do we have to do any porting because we
> > re-grab the library (ideally from a known stable version) with every
> > release.
>
> That's really cool.  Thanks for the info.
>
> I'm just very impressed with how clean the result is and there's the
> obvious benefit of those library versions not conflicting with any
> apps deployed without the need for fancy classloader scoping.

I can't take credit for the idea or the impl (I believe Remy was the
one who put it in), but it's certainly a simple solution that's worked
well for us.

Yoav

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

Juli/Logging

[David Blevins]

So another topic,

There's a thread going on in OpenEJB at the moment about possibly  
switching away from log4j for the reason that the logging config gets  
easily messed up in embedded environments (maven, specificaly) and of  
course to have one less dependency -- the 3.0 server is a bit beefier  
than the 1.0.


I remembered not seeing log4j or commons logging in Tomcat 6 and  
started investigating -- how I discovered the inlining.  Seems juli  
is a trimmed down version of commons-logging (attractive), but it  
isn't obvious what's driving the actual logging.  Didn't see any  
inlined log4j classes.  Are you using java.util.Logging or something  
else?


Also noticed the javadoc of juli says it allows for per-classloader  
configuration of logging.  What exactly does that mean?


Thanks!

-David


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

DO NOT REPLY [Bug 42996] - POST with nio connector results in missing variables

[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=42996





--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 13:30 ---
Some additional testing indicates that this MAY be the result of too low a value
for maxHttpHeaderSize.  My simple test of POST works as-expected, but posts with
my actual site don't seem to.  The inference I got from this was that the
content of the POST matters.  No idea why it would behave differently for nio vs
the standard connector though, unless the two have different defaults or react
differently when the default is exceeded.

I will do some more testing and report what I find.

-- 
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 42996] - POST with nio connector results in missing variables

[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=42996





--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 14:00 ---
Unfortunately, adjusting the maxHttpHeaderSize doesn't seem to fix the problem.

Strangely enough, though, it seems like having multiple Connectors defined with
at least one of them being the standard connector and the two sharing the same
executor pool makes the problem happen less frequently, though that could be my
imagination too.  Maybe there's some state that isn't getting reset for the
executors with the nio connector?

-- 
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 40668] - MailSessionFactory is missing in Tomcat 5.5.23

[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=40668





--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 14:20 ---
(In reply to comment #37)
> This still isn't fixed in the core binary distribution downloaded here:
> http://tomcat.apache.org/download-55.cgi#5.5.23

If I were holding my breath to have this problem fixed  well, lets just say
I'd be pushing up worms.

You can use this patch (taken from the Tomcat 5.5.17 distribution) to add the
required libraries to Tomcat 5.5.23 /common/classes folder:
http://issues.apache.org/bugzilla/attachment.cgi?id=19186

You can also download the 5.5.17 distribution and replace the
/common/lib/naming-factory.jar in your Tomcat 5.5.23 installation with the
5.5.17 version.
http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.17/bin/apache-tomcat-5.5.17.zip


-- 
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]

Re: Juli/Logging

[Rainer Jung]

Hi David,

our default bundled JULI only has a binding for java.util.logging. On

http://tomcat.apache.org/tomcat-6.0-doc/extras.html

there is a very short description, how one builds a JULI, that is log4j 
enabled. The static binding was chosen, because commons-logging auto 
detection provided to many problems w.r.t. redeployment and classloader 
leaks.


My personal opinion: java.util.logging very much lacks a good formatter. 
The default 2 line formatting of messages, splitting timestamps and 
message in separate lines, is not really useful in production. Many ad 
hoc log analysis practices work on a line oriented basis.


Regards,

Rainer

David Blevins wrote:

So another topic,

There's a thread going on in OpenEJB at the moment about possibly 
switching away from log4j for the reason that the logging config gets 
easily messed up in embedded environments (maven, specificaly) and of 
course to have one less dependency -- the 3.0 server is a bit beefier 
than the 1.0.


I remembered not seeing log4j or commons logging in Tomcat 6 and started 
investigating -- how I discovered the inlining.  Seems juli is a trimmed 
down version of commons-logging (attractive), but it isn't obvious 
what's driving the actual logging.  Didn't see any inlined log4j 
classes.  Are you using java.util.Logging or something else?


Also noticed the javadoc of juli says it allows for per-classloader 
configuration of logging.  What exactly does that mean?


Thanks!

-David


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



--
--
kippdata
informationstechnologie GmbH   Tel: 0228 98549 -0
Bornheimer Str. 33aFax: 0228 98549 -50
53111 Bonn www.kippdata.de

HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann
===
kippdata
informationstechnologie GmbH   Tel: +49 228 98549 -0
Bornheimer Str. 33aFax: +49 228 98549 -50
D-53111 Bonn   www.kippdata.de

HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann

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

How to dump out thread information in Tomcat 5?

[CW \(Chi Wo\) Chung]

Hi,
 
We have configured tomcat to use 150 threads, and once a while the
number was exceeded, and we have this error message.
>>> SEVERE: All threads (150) are currently busy, waiting. Increase
maxThreads (150) or check the servlet status

We know what file to change to increase the thread configuration. We
plan to change it to say 300 or even 500. However, I felt a bit  like
shooting in the dark without knowing whether this number of thread (15)
is exceeded because of normal usage, or due to exceptions/bugs/attack. 

Is there any configuration setting in Tomcat that I can turn on to dump
out the following:

- number of thread being used

-  who invoke which thread and what each thread is doing?

Even a partial answer is better than none.

 

Thanks very much!!

-cw-

CW Chung, Wireless Matrix, Mountain View, CA

 

=
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.

Thank you.

Re: How to dump out thread information in Tomcat 5?

[Yoav Shapira]

Hey,
This is the wrong mailing list: please use the Tomcat users mailing
list.  See instructions at  http://tomcat.apache.org/lists.html to
subscribe.  Please post followup, if any, there.

On 7/31/07, CW (Chi Wo) Chung <[EMAIL PROTECTED]> wrote:
> Is there any configuration setting in Tomcat that I can turn on to dump
> out the following:

Google is your friend ;)  This is not specific to Tomcat, but general
to JDK 1.4 (IIRC) and later:
http://www.crazysquirrel.com/computing/java/basics/java-thread-dump.jspx
(and many more, just google the relevant terms).

Yoav

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

DO NOT REPLY [Bug 42996] - POST with nio connector results in missing variables

[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=42996





--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 14:58 ---
At first glance, it looks like 6.0.14 fixes the problem.

-- 
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]

Re: Inlining dependencies

[William L. Thomson Jr.]

On Tue, 2007-07-31 at 14:59 -0400, Yoav Shapira wrote:
> > It's all done in Ant tasks: look for how
> the Tomcat build handles Jakarta Commons DBCP for example.

I absolutely despise how that is built. It makes building that jar a
complete NIGHTMARE. Presently we do not offer than jar on Gentoo and I
have no plans to. Or worse potential ways to.

Because I will have to hack around our packaging system to even make an
attempt. Hard coding versions of a libraries sources within another
package, and not as a package dependency. But as additional sources for
Tomcat :(. Despite a newer version of those libraries already existing
on the system. Which also means they have downloaded a copy of that
packages sources, but might not have installed the sources.

It is the oldest bug wrt to Tomcat on Gentoo :(
http://bugs.gentoo.org/buglist.cgi?quicksearch=tomcat

It came up in the past here, where others also disliked the process of
how it was built. But so far has fallen on deaf ears. I have not had the
time or chance to address the issue and provide you all with a code work
around.
http://marc.info/?l=tomcat-dev&m=115808287528288&w=2

>   We don't
> trim them down AFAIK, nor do we have to do any porting because we
> re-grab the library (ideally from a known stable version) with every
> release.

I see there are some slight modifications. Other than the re-branding
and re-packaging. Which at the end of the day I really fail to see the
benefit to this approach. Verses just shipping collections, pool, and
dbcp. 

Not to mention many drivers have their own factories. But recently as a
user discovered. This is not a valid work around for Global resources.
As that is hard coded no matter what is configured in server.xml to use
tomcat-dbcp.jar.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

Re: [VOTE] Release build 6.0.14

[Mark Thomas]

Remy Maucherat wrote:
> The candidates binaries are available here:
> http://people.apache.org/~remm/tomcat-6/v6.0.14/
> 
> According to the release process, the 6.0.14 tag is:
> [ ] Broken
> [ ] Alpha
> [ ] Beta
> [X] Stable

No issues found.

Mark

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

DO NOT REPLY [Bug 42922] - Comments not removed when using XML Syntax

[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=42922


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-07-31 19:03 ---
My bad. When I fixed bug 22802 I wasn't careful enough with the copy and paste
and introduced this problem.

The fix is now in svn and will be included in the next release.

Thanks for the report.

-- 
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: r561623 - in /tomcat: container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt jasper/branches/tc4.1.x/src/share/org/apache/jasper/compiler/JspDocumentParser.java

[markt]

Author: markt
Date: Tue Jul 31 19:22:56 2007
New Revision: 561623

URL: http://svn.apache.org/viewvc?view=rev&rev=561623
Log:
Fix bug 42922. Treat XML comments as comments in JSP documents

Modified:
tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt

tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/compiler/JspDocumentParser.java

Modified: tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt?view=diff&rev=561623&r1=561622&r2=561623
==
--- tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt (original)
+++ tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt Tue Jul 31 19:22:56 
2007
@@ -2399,6 +2399,10 @@
   whose target performs a 'forward' does not behave as
  expected
 
+[4.1.37] #42922
+ Generator
+ XML comments were treated as template text in JSP Documents
+
 
 
 KNOWN ISSUES IN THIS RELEASE:

Modified: 
tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/compiler/JspDocumentParser.java
URL: 
http://svn.apache.org/viewvc/tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/compiler/JspDocumentParser.java?view=diff&rev=561623&r1=561622&r2=561623
==
--- 
tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/compiler/JspDocumentParser.java
 (original)
+++ 
tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/compiler/JspDocumentParser.java
 Tue Jul 31 19:22:56 2007
@@ -1,9 +1,10 @@
 /*
- * Copyright 1999,2004 The Apache Software Foundation.
- * 
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
  * 
  *  http://www.apache.org/licenses/LICENSE-2.0
  * 
@@ -266,7 +267,7 @@
 if (!inDTD) {
 Mark start = new Mark(path, locator.getLineNumber(),
   locator.getColumnNumber());
-new Node.TemplateText(new String(buf, offset, len), start, 
current);
+new Node.Comment(new String(buf, offset, len), start, current);
 }
 }
 



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

Re: Juli/Logging

[David Blevins]

On Jul 31, 2007, at 2:27 PM, Rainer Jung wrote:


Hi David,

our default bundled JULI only has a binding for java.util.logging. On

http://tomcat.apache.org/tomcat-6.0-doc/extras.html

there is a very short description, how one builds a JULI, that is  
log4j enabled. The static binding was chosen, because commons- 
logging auto detection provided to many problems w.r.t.  
redeployment and classloader leaks.


Cool, thanks.

My personal opinion: java.util.logging very much lacks a good  
formatter. The default 2 line formatting of messages, splitting  
timestamps and message in separate lines, is not really useful in  
production. Many ad hoc log analysis practices work on a line  
oriented basis.


Was wondering about that.  I've heard people grumble about  
java.util.logging, but haven't (till now) heard anything specific.   
Maybe I wasn't paying close enough attention, but the Tomcat 6 log  
files still seem to follow the one line per message format.  How did  
you pull that off?


-David



Regards,

Rainer

David Blevins wrote:

So another topic,
There's a thread going on in OpenEJB at the moment about possibly  
switching away from log4j for the reason that the logging config  
gets easily messed up in embedded environments (maven,  
specificaly) and of course to have one less dependency -- the 3.0  
server is a bit beefier than the 1.0.
I remembered not seeing log4j or commons logging in Tomcat 6 and  
started investigating -- how I discovered the inlining.  Seems  
juli is a trimmed down version of commons-logging (attractive),  
but it isn't obvious what's driving the actual logging.  Didn't  
see any inlined log4j classes.  Are you using java.util.Logging or  
something else?
Also noticed the javadoc of juli says it allows for per- 
classloader configuration of logging.  What exactly does that mean?

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


--
--
kippdata
informationstechnologie GmbH   Tel: 0228 98549 -0
Bornheimer Str. 33aFax: 0228 98549 -50
53111 Bonn www.kippdata.de

HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann
===
kippdata
informationstechnologie GmbH   Tel: +49 228 98549 -0
Bornheimer Str. 33aFax: +49 228 98549 -50
D-53111 Bonn   www.kippdata.de

HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann

-
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]

Denis LULLIER/Paris est absent(e).

[dlullier]

Je serai absent(e) du  01/08/2007 au 27/08/2007.

Je répondrai à votre message dès mon retour. En cas d'urgence, vous pouvez
contacter Christine DUHAU ou Marc-Olivier JOUAN

Development of admin webapp

[Santosh [ಸಂತೋಷ ]]

Hi All,

As admin webapp is not supported in tomcat 6.0.x, i have taken admin
webapp of tomcat 5.5.23 and modified according to tomcat 6.0.7 code. Now my
admin webapp is up and running in tomcat 6.0.7. Following operations are
working in admin webapp,

1. Logging in
2. Updation to Tomcat Server (Server, Connector, Host)
3. Adding new host.

Following are not working,

1. Addition or deletion of resources.
2. Addition or deletion of User Definition.

Whenever i try these operations, i am getting HTTP 500 error and message is
"*Error invoking operation **addEnvironment*" (While adding environment
variables). I think mbean for
"Catalina:type=NamingResources,resourcetype=Global" is not
registered/created in tomcat 6.07.

Please someone help to get these working.

Regards,
Santosh