svn commit: r547096 - in /tomcat/trunk/java/org/apache: coyote/ajp/AjpAprProcessor.java coyote/ajp/AjpProcessor.java jk/common/HandlerRequest.java

[billbarker]

Author: billbarker
Date: Wed Jun 13 19:55:26 2007
New Revision: 547096

URL: http://svn.apache.org/viewvc?view=rev&rev=547096
Log:
Porting large-file support for the AJP Connectors from 5.5

Modified:
tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
tomcat/trunk/java/org/apache/jk/common/HandlerRequest.java

Modified: tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java?view=diff&rev=547096&r1=547095&r2=547096
==
--- tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java Wed Jun 13 
19:55:26 2007
@@ -680,7 +680,9 @@
 if (hId == Constants.SC_REQ_CONTENT_LENGTH ||
 (hId == -1 && tmpMB.equalsIgnoreCase("Content-Length"))) {
 // just read the content-length header, so set it
-request.setContentLength( vMB.getInt() );
+long cl = vMB.getLong();
+if(cl < Integer.MAX_VALUE)
+request.setContentLength( (int)cl );
 } else if (hId == Constants.SC_REQ_CONTENT_TYPE ||
 (hId == -1 && tmpMB.equalsIgnoreCase("Content-Type"))) {
 // just read the content-type header, so set it
@@ -1204,7 +1206,7 @@
 if (endOfStream) {
 return -1;
 }
-if (first && req.getContentLength() > 0) {
+if (first && req.getContentLengthLong() > 0) {
 // Handle special first-body-chunk
 if (!receive()) {
 return 0;

Modified: tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java?view=diff&rev=547096&r1=547095&r2=547096
==
--- tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java Wed Jun 13 
19:55:26 2007
@@ -688,7 +688,9 @@
 if (hId == Constants.SC_REQ_CONTENT_LENGTH ||
 (hId == -1 && tmpMB.equalsIgnoreCase("Content-Length"))) {
 // just read the content-length header, so set it
-request.setContentLength( vMB.getInt() );
+long cl = vMB.getLong();
+if(cl < Integer.MAX_VALUE)
+request.setContentLength( (int)cl );
 } else if (hId == Constants.SC_REQ_CONTENT_TYPE ||
 (hId == -1 && tmpMB.equalsIgnoreCase("Content-Type"))) {
 // just read the content-type header, so set it
@@ -1144,7 +1146,7 @@
 if (endOfStream) {
 return -1;
 }
-if (first && req.getContentLength() > 0) {
+if (first && req.getContentLengthLong() > 0) {
 // Handle special first-body-chunk
 if (!receive()) {
 return 0;

Modified: tomcat/trunk/java/org/apache/jk/common/HandlerRequest.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jk/common/HandlerRequest.java?view=diff&rev=547096&r1=547095&r2=547096
==
--- tomcat/trunk/java/org/apache/jk/common/HandlerRequest.java (original)
+++ tomcat/trunk/java/org/apache/jk/common/HandlerRequest.java Wed Jun 13 
19:55:26 2007
@@ -407,7 +407,7 @@
 
 // Check to see if there should be a body packet coming along
 // immediately after
-int cl=req.getContentLength();
+long cl=req.getContentLengthLong();
 if(cl > 0) {
 JkInputStream jkIS = ep.getInputStream();
 jkIS.setIsReadRequired(true);
@@ -577,7 +577,9 @@
 if (hId == AjpConstants.SC_REQ_CONTENT_LENGTH ||
 (hId == -1 && tmpMB.equalsIgnoreCase("Content-Length"))) {
 // just read the content-length header, so set it
-req.setContentLength( vMB.getInt() );
+long cl = vMB.getLong();
+if(cl < Integer.MAX_VALUE)
+req.setContentLength( (int)cl );
 } else if (hId == AjpConstants.SC_REQ_CONTENT_TYPE ||
 (hId == -1 && tmpMB.equalsIgnoreCase("Content-Type"))) {
 // just read the content-type header, so set it



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

[CVE-2007-2450]: Apache Tomcat XSS vulnerability in Manager

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2007-2450: Apache Tomcat XSS vulnerabilities in Manager

Severity: low (cross-site scripting)

Vendor:
The Apache Software Foundation

Versions Affected:
Tomcat 4.0.0 to 4.0.6
Tomcat 4.1.0 to 4.1.36
Tomcat 5.0.0 to 5.0.30
Tomcat 5.5.0 to 5.5.24
Tomcat 6.0.0 to 6.0.13

Description:
The Manager and Host Manager web applications do not escape some user
provided data before including it in the output. This enables a XSS
attack. The user must be logged in to the Manager or Host Manager web
application.

Mitigation:
1. Log out of the Manager or Host Manager application (close the
browser) once tasks requiring use of the manager have been completed.

Example:
http://example.com:8080/manager/html/upload";
method="post" enctype="multipart/form-data">




Credit:
These issues were discovered by Daiki Fukumori, Secure Sky Technology.

References:
http://tomcat.apache.org/security.html

Mark Thomas




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGcKdkb7IeiTPGAkMRAt1IAKCR47H3juKSvEdGwymOMCpKZdXi8wCgvrzl
aQy4/FihDqtrwRDLl0f/asA=
=RGcQ
-END PGP SIGNATURE-

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

[CVE-2007-2449] Apache Tomcat XSS vulnerabilities in the JSP examples

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2007-2449: Apache Tomcat XSS vulnerabilities in the JSP examples

Severity: low (cross-site scripting)

Vendor:
The Apache Software Foundation

Versions Affected:
Tomcat 4.0.0 to 4.0.6
Tomcat 4.1.0 to 4.1.36
Tomcat 5.0.0 to 5.0.30
Tomcat 5.5.0 to 5.5.24
Tomcat 6.0.0 to 6.0.13

Description:
The JSP examples web application displays does not escape some user
provided data before including it in the output. This enables a XSS
attack.

Mitigation:
1. Undeploy the examples web application(s).

Example:
http://host:port/jsp-examples/snp/snoop.jsp;alert()test.jsp

Credit:
These issues were discovered by an unknown security researcher and
reported to JPCERT.

References:
http://tomcat.apache.org/security.html

Mark Thomas




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGcKbJb7IeiTPGAkMRAi9BAKDsuoomGh2n9BYl7mT/tGEjQ+HIlQCdHjnU
zdreMwViLR/bDBnys5YkhPk=
=SK7+
-END PGP SIGNATURE-

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

svn commit: r547089 - in /tomcat/site/trunk: docs/security-4.html docs/security-5.html docs/security-6.html xdocs/security-4.xml xdocs/security-5.xml xdocs/security-6.xml

[markt]

Author: markt
Date: Wed Jun 13 19:20:24 2007
New Revision: 547089

URL: http://svn.apache.org/viewvc?view=rev&rev=547089
Log:
Add CVE-2007-2449 and CVE-2007-2450.

Modified:
tomcat/site/trunk/docs/security-4.html
tomcat/site/trunk/docs/security-5.html
tomcat/site/trunk/docs/security-6.html
tomcat/site/trunk/xdocs/security-4.xml
tomcat/site/trunk/xdocs/security-5.xml
tomcat/site/trunk/xdocs/security-6.xml

Modified: tomcat/site/trunk/docs/security-4.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-4.html?view=diff&rev=547089&r1=547088&r2=547089
==
--- tomcat/site/trunk/docs/security-4.html (original)
+++ tomcat/site/trunk/docs/security-4.html Wed Jun 13 19:20:24 2007
@@ -261,6 +261,20 @@
 
 
 
+important: Information disclosure
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3164";>
+   CVE-2005-3164
+
+
+If a client specifies a Content-Length but disconnects before sending
+   any of the request body, the deprecated AJP connector processes the
+   request using the request body of the previous request. Users are 
advised
+   to use the default, supported Coyote AJP connector which does not 
exhibit
+   this issue.
+
+Affects: 4.0.1-4.0.6, 4.1.0-4.1.36
+
+
 moderate: Cross-site scripting
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1355";>
CVE-2007-1355
@@ -272,43 +286,37 @@
simplified not to use any user provided data in the output.
 
 Affects: 4.0.1-4.0.6, 4.1.0-4.1.36
-  
+
+
+low: Cross-site scripting
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2449";>
+   CVE-2007-2449
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fixed in Apache Tomcat 4.1.HEAD
-
-
-
-
-
-
-
-
+
+JSPs within the examples web application did not escape user provided
+   data before including it in the output. This enabled a XSS attack. These
+   JSPs now filter the data before use. This issue may be mitigated by
+   undeploying the examples web application. Note that it is recommended
+   that the examples web application is not installed on a production
+   system.
+   
+
+Affects: 4.0.0-4.0.6, 4.1.0-4.1.36
+
 
-important: Information disclosure
-   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3164";>
-   CVE-2005-3164
+low: Cross-site scripting
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2450";>
+   CVE-2007-2450
 
 
-If a client specifies a Content-Length but disconnects before sending
-   any of the request body, the deprecated AJP connector processes the
-   request using the request body of the previous request. Users are 
advised
-   to use the default, supported Coyote AJP connector which does not 
exhibit
-   this issue.
+The Manager web application did not escape user provided data before
+   including it in the output. This enabled a XSS attack. This applciation
+   now filters the data before use. This issue may be mitigated by logging
+   out (closing the browser) of the application once the management tasks
+   have been completed.
 
 Affects: 4.0.1-4.0.6, 4.1.0-4.1.36
+
   
 
 

Modified: tomcat/site/trunk/docs/security-5.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-5.html?view=diff&rev=547089&r1=547088&r2=547089
==
--- tomcat/site/trunk/docs/security-5.html (original)
+++ tomcat/site/trunk/docs/security-5.html Wed Jun 13 19:20:24 2007
@@ -222,6 +222,60 @@
 
 
 
+low: Cross-site scripting
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2449";>
+   CVE-2007-2449
+
+
+JSPs within the examples web application did not escape user provided
+   data before including it in the output. This enabled a XSS attack. These
+   JSPs now filter the data before use. This issue may be mitigated by
+   undeploying the examples web application. Note that it is recommended
+   that the examples web application is not installed on a production
+   system.
+   
+
+Affects: 5.0.0-5.0.30, 5.5.0-5.5.24
+
+
+low: Cross-site scripting
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2450";>
+   CVE-2007-2450
+
+
+The Manager and Host Manager web applications did not escape user
+   provided data before including it in the output. This enabled a XSS
+   attack. These applciations now filter the data before use. This issue 
may
+   be mitigated by logging out (closing the browser) of the application 
once
+   the management tasks have been completed.
+
+Affects: 5.0.0-5.0.30, 5.5.0-5.5.24
+
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fixed in Apache Tomcat 5.5.24, 5.0.HEAD
+
+
+
+
+
+
+
+
+
 moderate: Cross-site scripting
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1355";>
CVE-2007-1355
@@ -23

svn commit: r547088 - /tomcat/container/branches/tc5.0.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java

[markt]

Author: markt
Date: Wed Jun 13 19:17:22 2007
New Revision: 547088

URL: http://svn.apache.org/viewvc?view=rev&rev=547088
Log:
Port fix for XSS issue in Manager. This is CVE-2007-2450.

Modified:

tomcat/container/branches/tc5.0.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java

Modified: 
tomcat/container/branches/tc5.0.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc5.0.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java?view=diff&rev=547088&r1=547087&r2=547088
==
--- 
tomcat/container/branches/tc5.0.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
 (original)
+++ 
tomcat/container/branches/tc5.0.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
 Wed Jun 13 19:17:22 2007
@@ -106,9 +106,7 @@
 } else if (command.equals("/stop")) {
 message = stop(path);
 } else {
-message =
-sm.getString("managerServlet.unknownCommand",
-RequestUtil.filter(command));
+message = sm.getString("managerServlet.unknownCommand", command);
 }
 
 list(request, response, message);
@@ -306,7 +304,11 @@
 // Message Section
 args = new Object[3];
 args[0] = sm.getString("htmlManagerServlet.messageLabel");
-args[1] = (message == null || message.length() == 0) ? "OK" : message;
+if (message == null || message.length() == 0) {
+args[1] = "OK";
+} else {
+args[1] = RequestUtil.filter(message);
+}
 writer.print(MessageFormat.format(Constants.MESSAGE_SECTION, args));
 
 // Manager Section



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

svn commit: r547087 - in /tomcat/container/branches/tc4.1.x/webapps/examples/jsp: security/protected/index.jsp snp/snoop.html snp/snoop.jsp snp/snoop.txt source.jsp

[markt]

Author: markt
Date: Wed Jun 13 19:14:55 2007
New Revision: 547087

URL: http://svn.apache.org/viewvc?view=rev&rev=547087
Log:
Port fix for XSS issues in snoop.jsp. This is CVE-2007-2449.

Modified:

tomcat/container/branches/tc4.1.x/webapps/examples/jsp/security/protected/index.jsp
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.html
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.jsp
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.txt
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/source.jsp

Modified: 
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/security/protected/index.jsp
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/webapps/examples/jsp/security/protected/index.jsp?view=diff&rev=547087&r1=547086&r2=547087
==
--- 
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/security/protected/index.jsp
 (original)
+++ 
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/security/protected/index.jsp
 Wed Jun 13 19:14:55 2007
@@ -1,3 +1,19 @@
+
 <%
   if (request.getParameter("logoff") != null) {
 session.invalidate();
@@ -11,14 +27,16 @@
 
 
 
-You are logged in as remote user <%= request.getRemoteUser() %>
+You are logged in as remote user
+<%= util.HTMLFilter.filter(request.getRemoteUser()) %>
 in session <%= session.getId() %>
 
 <%
   if (request.getUserPrincipal() != null) {
 %>
 Your user principal name is
-<%= request.getUserPrincipal().getName() %>
+<%= util.HTMLFilter.filter(request.getUserPrincipal().getName()) %>
+
 <%
   } else {
 %>

Modified: tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.html
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.html?view=diff&rev=547087&r1=547086&r2=547087
==
--- tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.html 
(original)
+++ tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.html Wed 
Jun 13 19:14:55 2007
@@ -1,7 +1,19 @@
 
 
 
 
@@ -10,10 +22,10 @@
 
 
 
-
+
 
-Source Code for Request Parameters Example
-   
+Source Code for Request Parameters Example
+  
 
 
 

Modified: tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.jsp
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.jsp?view=diff&rev=547087&r1=547086&r2=547087
==
--- tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.jsp 
(original)
+++ tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.jsp Wed 
Jun 13 19:14:55 2007
@@ -1,43 +1,56 @@
 
 
 
 
  Request Information 
 
-JSP Request Method: <% out.print(util.HTMLFilter.filter(request.getMethod())); 
%>
+JSP Request Method: <%= util.HTMLFilter.filter(request.getMethod()) %>
 
-Request URI: <%= request.getRequestURI() %>
+Request URI: <%= util.HTMLFilter.filter(request.getRequestURI()) %>
 
-Request Protocol: <%= request.getProtocol() %>
+Request Protocol: <%= util.HTMLFilter.filter(request.getProtocol()) %>
 
-Servlet path: <%= request.getServletPath() %>
+Servlet path: <%= util.HTMLFilter.filter(request.getServletPath()) %>
 
-Path info: <% out.print(util.HTMLFilter.filter(request.getPathInfo())); %>
+Path info: <%= util.HTMLFilter.filter(request.getPathInfo()) %>
 
-Query string: <% out.print(util.HTMLFilter.filter(request.getQueryString())); 
%>
+Query string: <%= util.HTMLFilter.filter(request.getQueryString()) %>
 
 Content length: <%= request.getContentLength() %>
 
-Content type: <% out.print(util.HTMLFilter.filter(request.getContentType())); 
%>
+Content type: <%= util.HTMLFilter.filter(request.getContentType()) %>
 
-Server name: <%= request.getServerName() %>
+Server name: <%= util.HTMLFilter.filter(request.getServerName()) %>
 
 Server port: <%= request.getServerPort() %>
 
-Remote user: <%= request.getRemoteUser() %>
+Remote user: <%= util.HTMLFilter.filter(request.getRemoteUser()) %>
 
-Remote address: <%= request.getRemoteAddr() %>
+Remote address: <%= util.HTMLFilter.filter(request.getRemoteAddr()) %>
 
-Remote host: <%= request.getRemoteHost() %>
+Remote host: <%= util.HTMLFilter.filter(request.getRemoteHost()) %>
 
-Authorization scheme: <%= request.getAuthType() %> 
+Authorization scheme: <%= util.HTMLFilter.filter(request.getAuthType()) %> 
 
 Locale: <%= request.getLocale() %>
 
-The browser you are using is <% 
out.print(util.HTMLFilter.filter(request.getHeader("User-Agent"))); %>
+The browser you are using is
+<%= util.HTMLFilter.filter(request.getHeader("User-Agent")) %>
 
 
 

Modified: tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.txt
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.txt?view=diff&rev=547087&r1=54708

svn commit: r547085 - /tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java

[markt]

Author: markt
Date: Wed Jun 13 19:13:59 2007
New Revision: 547085

URL: http://svn.apache.org/viewvc?view=rev&rev=547085
Log:
Port fix for XSS issue in Manager. This is CVE-2007-2450.

Modified:

tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java

Modified: 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java?view=diff&rev=547085&r1=547084&r2=547085
==
--- 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
 (original)
+++ 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
 Wed Jun 13 19:13:59 2007
@@ -113,8 +113,7 @@
 message = stop(path);
 } else {
 message =
-sm.getString("managerServlet.unknownCommand",
- RequestUtil.filter(command));
+sm.getString("managerServlet.unknownCommand",command);
 }
 
 list(request, response, message);
@@ -317,7 +316,11 @@
 // Message Section
 args = new Object[3];
 args[0] = sm.getString("htmlManagerServlet.messageLabel");
-args[1] = (message == null || message.length() == 0) ? "OK" : message;
+if (message == null || message.length() == 0) {
+args[1] = "OK";
+} else {
+args[1] = RequestUtil.filter(message);
+}
 writer.print(MessageFormat.format(MESSAGE_SECTION, args));
 
 // Manager Section



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

svn commit: r547083 - in /tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples: security/protected/index.jsp snp/snoop.html snp/snoop.jsp source.jsp

[markt]

Author: markt
Date: Wed Jun 13 19:12:38 2007
New Revision: 547083

URL: http://svn.apache.org/viewvc?view=rev&rev=547083
Log:
Port fix for XSS issues in snoop.jsp. This is CVE-2007-2449.

Modified:

tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.html
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.jsp
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/source.jsp

Modified: 
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp
URL: 
http://svn.apache.org/viewvc/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp?view=diff&rev=547083&r1=547082&r2=547083
==
--- 
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp
 (original)
+++ 
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp
 Wed Jun 13 19:12:38 2007
@@ -27,14 +27,16 @@
 
 
 
-You are logged in as remote user <%= request.getRemoteUser() %>
+You are logged in as remote user
+<%= util.HTMLFilter.filter(request.getRemoteUser()) %>
 in session <%= session.getId() %>
 
 <%
   if (request.getUserPrincipal() != null) {
 %>
 Your user principal name is
-<%= request.getUserPrincipal().getName() %>
+<%= util.HTMLFilter.filter(request.getUserPrincipal().getName()) %>
+
 <%
   } else {
 %>

Modified: 
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.html
URL: 
http://svn.apache.org/viewvc/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.html?view=diff&rev=547083&r1=547082&r2=547083
==
--- tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.html 
(original)
+++ tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.html 
Wed Jun 13 19:12:38 2007
@@ -24,8 +24,8 @@
 
 
 
-Source Code for Request Parameters Example
-   
+Source Code for Request Parameters Example
+  
 
 
 

Modified: 
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.jsp
URL: 
http://svn.apache.org/viewvc/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.jsp?view=diff&rev=547083&r1=547082&r2=547083
==
--- tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.jsp 
(original)
+++ tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.jsp Wed 
Jun 13 19:12:38 2007
@@ -19,37 +19,38 @@
 
  Request Information 
 
-JSP Request Method: <% out.print(util.HTMLFilter.filter(request.getMethod())); 
%>
+JSP Request Method: <%= util.HTMLFilter.filter(request.getMethod()) %>
 
-Request URI: <%= request.getRequestURI() %>
+Request URI: <%= util.HTMLFilter.filter(request.getRequestURI()) %>
 
-Request Protocol: <%= request.getProtocol() %>
+Request Protocol: <%= util.HTMLFilter.filter(request.getProtocol()) %>
 
-Servlet path: <%= request.getServletPath() %>
+Servlet path: <%= util.HTMLFilter.filter(request.getServletPath()) %>
 
-Path info: <% out.print(util.HTMLFilter.filter(request.getPathInfo())); %>
+Path info: <%= util.HTMLFilter.filter(request.getPathInfo()) %>
 
-Query string: <% out.print(util.HTMLFilter.filter(request.getQueryString())); 
%>
+Query string: <%= util.HTMLFilter.filter(request.getQueryString()) %>
 
 Content length: <%= request.getContentLength() %>
 
-Content type: <% out.print(util.HTMLFilter.filter(request.getContentType())); 
%>
+Content type: <%= util.HTMLFilter.filter(request.getContentType()) %>
 
-Server name: <%= request.getServerName() %>
+Server name: <%= util.HTMLFilter.filter(request.getServerName()) %>
 
 Server port: <%= request.getServerPort() %>
 
-Remote user: <%= request.getRemoteUser() %>
+Remote user: <%= util.HTMLFilter.filter(request.getRemoteUser()) %>
 
-Remote address: <%= request.getRemoteAddr() %>
+Remote address: <%= util.HTMLFilter.filter(request.getRemoteAddr()) %>
 
-Remote host: <%= request.getRemoteHost() %>
+Remote host: <%= util.HTMLFilter.filter(request.getRemoteHost()) %>
 
-Authorization scheme: <%= request.getAuthType() %> 
+Authorization scheme: <%= util.HTMLFilter.filter(request.getAuthType()) %> 
 
 Locale: <%= request.getLocale() %>
 
-The browser you are using is <% 
out.print(util.HTMLFilter.filter(request.getHeader("User-Agent"))); %>
+The browser you are using is
+<%= util.HTMLFilter.filter(request.getHeader("User-Agent")) %>
 
 
 

Modified: tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/source.jsp
URL: 
http://svn.apache.org/viewvc/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/source.jsp?view=diff&rev=547083&r1=547082&r2=547083
==
--- tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/source

svn commit: r547082 - in /tomcat/container/tc5.5.x/webapps: host-manager/WEB-INF/classes/org/apache/catalina/hostmanager/HTMLHostManagerServlet.java manager/WEB-INF/classes/org/apache/catalina/manager

[markt]

Author: markt
Date: Wed Jun 13 19:12:04 2007
New Revision: 547082

URL: http://svn.apache.org/viewvc?view=rev&rev=547082
Log:
Port fix for XSS issue in Manager and Host Manager. This is CVE-2007-2450.

Modified:

tomcat/container/tc5.5.x/webapps/host-manager/WEB-INF/classes/org/apache/catalina/hostmanager/HTMLHostManagerServlet.java

tomcat/container/tc5.5.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java

Modified: 
tomcat/container/tc5.5.x/webapps/host-manager/WEB-INF/classes/org/apache/catalina/hostmanager/HTMLHostManagerServlet.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/host-manager/WEB-INF/classes/org/apache/catalina/hostmanager/HTMLHostManagerServlet.java?view=diff&rev=547082&r1=547081&r2=547082
==
--- 
tomcat/container/tc5.5.x/webapps/host-manager/WEB-INF/classes/org/apache/catalina/hostmanager/HTMLHostManagerServlet.java
 (original)
+++ 
tomcat/container/tc5.5.x/webapps/host-manager/WEB-INF/classes/org/apache/catalina/hostmanager/HTMLHostManagerServlet.java
 Wed Jun 13 19:12:04 2007
@@ -32,6 +32,7 @@
 
 import org.apache.catalina.Container;
 import org.apache.catalina.Host;
+import org.apache.catalina.util.RequestUtil;
 import org.apache.catalina.util.ServerInfo;
 
 /**
@@ -195,7 +196,11 @@
 // Message Section
 args = new Object[3];
 args[0] = sm.getString("htmlHostManagerServlet.messageLabel");
-args[1] = (message == null || message.length() == 0) ? "OK" : message;
+if (message == null || message.length() == 0) {
+args[1] = "OK";
+} else {
+args[1] = RequestUtil.filter(message);
+}
 writer.print(MessageFormat.format(Constants.MESSAGE_SECTION, args));
 
 // Manager Section

Modified: 
tomcat/container/tc5.5.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java?view=diff&rev=547082&r1=547081&r2=547082
==
--- 
tomcat/container/tc5.5.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
 (original)
+++ 
tomcat/container/tc5.5.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
 Wed Jun 13 19:12:04 2007
@@ -107,8 +107,7 @@
 message = stop(path);
 } else {
 message =
-sm.getString("managerServlet.unknownCommand",
- RequestUtil.filter(command));
+sm.getString("managerServlet.unknownCommand", command);
 }
 
 list(request, response, message);
@@ -282,7 +281,11 @@
 // Message Section
 args = new Object[3];
 args[0] = sm.getString("htmlManagerServlet.messageLabel");
-args[1] = (message == null || message.length() == 0) ? "OK" : message;
+if (message == null || message.length() == 0) {
+args[1] = "OK";
+} else {
+args[1] = RequestUtil.filter(message);
+}
 writer.print(MessageFormat.format(Constants.MESSAGE_SECTION, args));
 
 // Manager Section



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

svn commit: r547081 - in /tomcat/tc6.0.x/trunk/webapps/examples/jsp: security/protected/index.jsp snp/snoop.html snp/snoop.jsp source.jsp

[markt]

Author: markt
Date: Wed Jun 13 19:01:19 2007
New Revision: 547081

URL: http://svn.apache.org/viewvc?view=rev&rev=547081
Log:
Fix XSS issues in snoop.jsp. This is CVE-2007-2449. Some of these are harder 
(impossible?) to exploit than others but doing all of them means there won't be 
another XSS issue to patch later.
I also made a similar change for a couple of other JSPs that are in the 
harder/impossible? to exploit category.

Modified:
tomcat/tc6.0.x/trunk/webapps/examples/jsp/security/protected/index.jsp
tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.html
tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.jsp
tomcat/tc6.0.x/trunk/webapps/examples/jsp/source.jsp

Modified: tomcat/tc6.0.x/trunk/webapps/examples/jsp/security/protected/index.jsp
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/examples/jsp/security/protected/index.jsp?view=diff&rev=547081&r1=547080&r2=547081
==
--- tomcat/tc6.0.x/trunk/webapps/examples/jsp/security/protected/index.jsp 
(original)
+++ tomcat/tc6.0.x/trunk/webapps/examples/jsp/security/protected/index.jsp Wed 
Jun 13 19:01:19 2007
@@ -27,14 +27,16 @@
 
 
 
-You are logged in as remote user <%= request.getRemoteUser() %>
+You are logged in as remote user
+<%= util.HTMLFilter.filter(request.getRemoteUser()) %>
 in session <%= session.getId() %>
 
 <%
   if (request.getUserPrincipal() != null) {
 %>
 Your user principal name is
-<%= request.getUserPrincipal().getName() %>
+<%= util.HTMLFilter.filter(request.getUserPrincipal().getName()) %>
+
 <%
   } else {
 %>

Modified: tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.html
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.html?view=diff&rev=547081&r1=547080&r2=547081
==
--- tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.html (original)
+++ tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.html Wed Jun 13 
19:01:19 2007
@@ -24,8 +24,8 @@
 
 
 
-Source Code for Request Parameters Example
-   
+Source Code for Request Parameters Example
+  
 
 
 

Modified: tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.jsp
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.jsp?view=diff&rev=547081&r1=547080&r2=547081
==
--- tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.jsp (original)
+++ tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.jsp Wed Jun 13 19:01:19 
2007
@@ -19,37 +19,38 @@
 
  Request Information 
 
-JSP Request Method: <% out.print(util.HTMLFilter.filter(request.getMethod())); 
%>
+JSP Request Method: <%= util.HTMLFilter.filter(request.getMethod()) %>
 
-Request URI: <%= request.getRequestURI() %>
+Request URI: <%= util.HTMLFilter.filter(request.getRequestURI()) %>
 
-Request Protocol: <%= request.getProtocol() %>
+Request Protocol: <%= util.HTMLFilter.filter(request.getProtocol()) %>
 
-Servlet path: <%= request.getServletPath() %>
+Servlet path: <%= util.HTMLFilter.filter(request.getServletPath()) %>
 
-Path info: <% out.print(util.HTMLFilter.filter(request.getPathInfo())); %>
+Path info: <%= util.HTMLFilter.filter(request.getPathInfo()) %>
 
-Query string: <% out.print(util.HTMLFilter.filter(request.getQueryString())); 
%>
+Query string: <%= util.HTMLFilter.filter(request.getQueryString()) %>
 
 Content length: <%= request.getContentLength() %>
 
-Content type: <% out.print(util.HTMLFilter.filter(request.getContentType())); 
%>
+Content type: <%= util.HTMLFilter.filter(request.getContentType()) %>
 
-Server name: <%= request.getServerName() %>
+Server name: <%= util.HTMLFilter.filter(request.getServerName()) %>
 
 Server port: <%= request.getServerPort() %>
 
-Remote user: <%= request.getRemoteUser() %>
+Remote user: <%= util.HTMLFilter.filter(request.getRemoteUser()) %>
 
-Remote address: <%= request.getRemoteAddr() %>
+Remote address: <%= util.HTMLFilter.filter(request.getRemoteAddr()) %>
 
-Remote host: <%= request.getRemoteHost() %>
+Remote host: <%= util.HTMLFilter.filter(request.getRemoteHost()) %>
 
-Authorization scheme: <%= request.getAuthType() %> 
+Authorization scheme: <%= util.HTMLFilter.filter(request.getAuthType()) %> 
 
 Locale: <%= request.getLocale() %>
 
-The browser you are using is <% 
out.print(util.HTMLFilter.filter(request.getHeader("User-Agent"))); %>
+The browser you are using is
+<%= util.HTMLFilter.filter(request.getHeader("User-Agent")) %>
 
 
 

Modified: tomcat/tc6.0.x/trunk/webapps/examples/jsp/source.jsp
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/examples/jsp/source.jsp?view=diff&rev=547081&r1=547080&r2=547081
==
--- tomcat/tc6.0.x/trunk/webapps/examples/jsp/source.jsp (original)
+++ tomcat/tc6.0.x/trunk/webapps/examples/jsp/sourc

svn commit: r547079 - /tomcat/tc6.0.x/trunk/

[markt]

Author: markt
Date: Wed Jun 13 18:57:01 2007
New Revision: 547079

URL: http://svn.apache.org/viewvc?view=rev&rev=547079
Log:
Ignore local build properties

Modified:
tomcat/tc6.0.x/trunk/   (props changed)

Propchange: tomcat/tc6.0.x/trunk/
--
--- svn:ignore (original)
+++ svn:ignore Wed Jun 13 18:57:01 2007
@@ -1,2 +1,3 @@
 output
 .settings
+build.properties



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

svn commit: r547078 - in /tomcat/tc6.0.x/trunk/java/org/apache: coyote/ajp/AjpAprProcessor.java coyote/ajp/AjpProcessor.java jk/common/HandlerRequest.java

[billbarker]

Author: billbarker
Date: Wed Jun 13 18:56:16 2007
New Revision: 547078

URL: http://svn.apache.org/viewvc?view=rev&rev=547078
Log:
Porting large-file support for the AJP Connectors from 5.5

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
tomcat/tc6.0.x/trunk/java/org/apache/jk/common/HandlerRequest.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java?view=diff&rev=547078&r1=547077&r2=547078
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java Wed 
Jun 13 18:56:16 2007
@@ -680,7 +680,9 @@
 if (hId == Constants.SC_REQ_CONTENT_LENGTH ||
 (hId == -1 && tmpMB.equalsIgnoreCase("Content-Length"))) {
 // just read the content-length header, so set it
-request.setContentLength( vMB.getInt() );
+long cl = vMB.getLong();
+if(cl < Integer.MAX_VALUE)
+request.setContentLength( (int)cl );
 } else if (hId == Constants.SC_REQ_CONTENT_TYPE ||
 (hId == -1 && tmpMB.equalsIgnoreCase("Content-Type"))) {
 // just read the content-type header, so set it
@@ -1204,7 +1206,7 @@
 if (endOfStream) {
 return -1;
 }
-if (first && req.getContentLength() > 0) {
+if (first && req.getContentLengthLong() > 0) {
 // Handle special first-body-chunk
 if (!receive()) {
 return 0;

Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java?view=diff&rev=547078&r1=547077&r2=547078
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java Wed Jun 
13 18:56:16 2007
@@ -688,7 +688,9 @@
 if (hId == Constants.SC_REQ_CONTENT_LENGTH ||
 (hId == -1 && tmpMB.equalsIgnoreCase("Content-Length"))) {
 // just read the content-length header, so set it
-request.setContentLength( vMB.getInt() );
+long cl = vMB.getLong();
+if(cl < Integer.MAX_VALUE)
+request.setContentLength( (int)cl );
 } else if (hId == Constants.SC_REQ_CONTENT_TYPE ||
 (hId == -1 && tmpMB.equalsIgnoreCase("Content-Type"))) {
 // just read the content-type header, so set it
@@ -1144,7 +1146,7 @@
 if (endOfStream) {
 return -1;
 }
-if (first && req.getContentLength() > 0) {
+if (first && req.getContentLengthLong() > 0) {
 // Handle special first-body-chunk
 if (!receive()) {
 return 0;

Modified: tomcat/tc6.0.x/trunk/java/org/apache/jk/common/HandlerRequest.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jk/common/HandlerRequest.java?view=diff&rev=547078&r1=547077&r2=547078
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jk/common/HandlerRequest.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jk/common/HandlerRequest.java Wed Jun 
13 18:56:16 2007
@@ -407,7 +407,7 @@
 
 // Check to see if there should be a body packet coming along
 // immediately after
-int cl=req.getContentLength();
+long cl=req.getContentLengthLong();
 if(cl > 0) {
 JkInputStream jkIS = ep.getInputStream();
 jkIS.setIsReadRequired(true);
@@ -577,7 +577,9 @@
 if (hId == AjpConstants.SC_REQ_CONTENT_LENGTH ||
 (hId == -1 && tmpMB.equalsIgnoreCase("Content-Length"))) {
 // just read the content-length header, so set it
-req.setContentLength( vMB.getInt() );
+long cl = vMB.getLong();
+if(cl < Integer.MAX_VALUE) 
+req.setContentLength( (int)cl );
 } else if (hId == AjpConstants.SC_REQ_CONTENT_TYPE ||
 (hId == -1 && tmpMB.equalsIgnoreCase("Content-Type"))) {
 // just read the content-type header, so set it



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

svn commit: r547077 - in /tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager: HTMLManagerServlet.java host/HTMLHostManagerServlet.java

[markt]

Author: markt
Date: Wed Jun 13 18:55:09 2007
New Revision: 547077

URL: http://svn.apache.org/viewvc?view=rev&rev=547077
Log:
Fix XSS issue in Manager and Host Manager. This is CVE-2007-2450.

Modified:

tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java

tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java?view=diff&rev=547077&r1=547076&r2=547077
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java 
Wed Jun 13 18:55:09 2007
@@ -130,8 +130,7 @@
 message = stop(path);
 } else {
 message =
-sm.getString("managerServlet.unknownCommand",
- RequestUtil.filter(command));
+sm.getString("managerServlet.unknownCommand", command);
 }
 
 list(request, response, message);
@@ -305,7 +304,11 @@
 // Message Section
 args = new Object[3];
 args[0] = sm.getString("htmlManagerServlet.messageLabel");
-args[1] = (message == null || message.length() == 0) ? "OK" : message;
+if (message == null || message.length() == 0) {
+args[1] = "OK";
+} else {
+args[1] = RequestUtil.filter(message);
+}
 writer.print(MessageFormat.format(Constants.MESSAGE_SECTION, args));
 
 // Manager Section

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java?view=diff&rev=547077&r1=547076&r2=547077
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java
 (original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java
 Wed Jun 13 18:55:09 2007
@@ -32,6 +32,7 @@
 
 import org.apache.catalina.Container;
 import org.apache.catalina.Host;
+import org.apache.catalina.util.RequestUtil;
 import org.apache.catalina.util.ServerInfo;
 
 /**
@@ -195,7 +196,11 @@
 // Message Section
 args = new Object[3];
 args[0] = sm.getString("htmlHostManagerServlet.messageLabel");
-args[1] = (message == null || message.length() == 0) ? "OK" : message;
+if (message == null || message.length() == 0) {
+args[1] = "OK";
+} else {
+args[1] = RequestUtil.filter(message);
+}
 writer.print(MessageFormat.format(Constants.MESSAGE_SECTION, args));
 
 // Manager Section



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

Re: Proposed simplification of CometEvent

[Costin Manolache]

>
>
> Sounds better - but as Remy explained you would first need to explain
> why blocking is needed in this context and how to deal with the
confusion
> of mixing blocking and non-blocking for users, and the implementation
> complexities it adds.
trunk doesn't mix them. a comet connection is either blocking or non
blocking, it doesn't shift between the two,
and it allows developers to choose what they want. Just like a
SocketChannel in java.nio.
there is nothing confusing about that, unless java.nio is confusing :)




Well, nio is far from perfect - but that's not the point.

Servlets have a very nice blocking mechanism already - it's the servlet API
:-).
The question is why would you need to have a Commet connection blocking.

I think it's very reasonable to add a blocking waitForEvent() to allow
servlets have a
simpler ( but less efficient ) implementation.

Think about utilities that take the event as param - would they need to
check first
if it's blocking or not ? And what would blocking give you in addition to
waitForEvent() -
which is actually better since it allows you to un-block on any event, not
only a specific
read/write.



>
>>
>> > - please don't call the method configure(), it's commonly used with a
>> > different meaning ( i.e. setting the port or general configuration).
>> > setConnectionMode, etc. And using the enum doesn't sound consistent
>> with
>> > other APIs either.
>> we can call it whatever we want. But saying not using enum, its not
>> consistent with other APIs in Tomcat,
>> means would never take advantage of new language features ever, I think
>> that would be a shame.
>
>
> Same as above - the question is not about using new features, but if the
> features
> fit the use. I have no problem with using enums for the event types -
> just
> for
> configure, in the context of configure(enum) versus setBlocking(),
> setFoo().
this has been adjusted based on the feedback, the method is now
configureBlocking(boolean)
the state of it can be used by calling isBlocking()

register is using enums, mainly cause Remy, while he was working with
this API insisted on it.
I had preferred using an int, just like the socket API, but since Remy
had initially agreed to register, and proposed enum and unregister
we went with that.



Ok.




>
>
>
>
>> > - see bellow - I don't think I understand the benefits of mixing
>> blocking
>> > and non-blocking in this interface, it is quite confusing.
>> It would be mixing it, its a one time config, during the BEGIN event,
>> you say
>> configureBlocking(true) or configureBlocking(false).
>> Comet is very much connection centric, so you can't mix it.
>>
>> In the trunk API, its clear to what you are using, blocking or non
>> blocking, in the sandbox API, the swap
>> of it happens when invoking isWriteable or isReadable, making the state
>> of the comet connection confusing to the developer.
>
>
> I'm not sure it's true - my understanding is that sandbox is all
> non-blocking.
> Invoking isWriteable is not blocking.
>
> I think it would be ok to add a blocking waitForEvent() - combined with
> isReadable()/isWriteable()
this would be a dead lock, as the Comet API must guarantee that a
CometProcessor.event
is only invoked by one worker thread at any time. The blocking you are
talking about can be done
using an async thread can be done by registering for the event you wish
to be notified in and then
maybe await a latch countdown, or doing a sync/wait() combo.



What would happen in the blocking case when a different event happens ?
Isn't it the same, if you want to guarantee single-threaded behaviour ?

Well - is there any docs on what is the intended thread model of comet
servlets,
i.e. SingelThreaded or reentrant ? Multiple events can happen at same time
( or very close -
one event soon after a Comet servlet is called, before it returns), so this
is a general problem.



it will allow a sort-of blocking model. But having methods that are
> blocking
> sometimes
> and sometimes not - based on some config - is dangerous and confusing.
As I mentioned, the trunk Comet API is actually very similar to java.nio
API, hence developers familiar with that will instantly recognize
themselves and should get comfortable with the API.



I still don't recognize it as NIO :-), and I am not very comfortable with
the
changes between blocking and non-blocking in NIO ( including all the crazy
things that can happen only in the IO thread ).


Here are some of the things that might need to be clarified about the

trunk API:

1. It is possible to not be registered for any events, and even do
polling for data asynchronously




You would still get the BEGIN event I assume.

All you need to poll data async is waitForEvent(), or select() if you like
to emulate nio.

2. ERROR and END events, are an exception, you cant unregister for

those, as those might require the
   underlying socket to be closed, or has already been closed



In what thread would you get those ( in blocking mode

Re: Proposed simplification of CometEvent

[Filip Hanik - Dev Lists]

here we go, some examples

http://people.apache.org/~fhanik/tomcat/aio.html#Example%20code%20snippets

and the entire document has been updated to reflect most changes
http://people.apache.org/~fhanik/tomcat/aio.html


Filip

Filip Hanik - Dev Lists wrote:

I'll work on some examples to illustrate what I mean,
It will be much clearer

Filip

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

Ok, let me see if I can summarize.

1. Whether you write out the stored buffer using the Poller thread, 
or a Tomcat worker thread (flushed in Http11xxxProcessor) as 
described below I originally thought of this as async write, as we 
are simply doing a write with another one of our threads. Originally 
when we were talking non blocking writes, I was thinking along the 
lines of non blocking to where the Comet developer had to do that 
logic, just as he was writing a socket, possibly like (but not 
suggested) a CometEvent.nonBlockWrite(ByteBuffer).


2. Do we need non blocking? with the methods of isWriteable and the 
ability to register(OP_WRITE)->event(WRITE), if the number of bytes 
you write is usually smaller than the socket buffer, chances are 
that most writes will be non blocking. I would even argue a large 
majority would be non blocking, and thus the implementation or the 
complexity thereof would not be needed. And with the ability to do 
async writes, means I can create my own thread pool/write queue to 
perform these writes.


You are writing the opposite thing to the previous email, and we are 
back to "non blocking is useless". The problem is that I understand 
blocking IO as "write this data, and return when it's done". If the 
socket is in blocking mode, any write done by the servlet may block, 
regardless of what isWriteable says. Of course, it's very unlikely, 
which is why Comet in 6.0.x works.


3. isWriteable - simple method, but I don't like that the method in 
itself performs actions like adding the socket to a poller etc.
  Instead isWriteable==true means that you can write on the socket, 
isWriteable==false you cannot. This method should be able to be 
invoked as many times as its wanted, and is thread safe and doesn't 
do anything funky underneath.


Ok, so you prefer a more complex API (if I follow "just in case it 
was useful"). I started with an API which would expose all 
operations, and looked into removing what was not explicitly useful.


4. isWriteable - I'm also reading in that you are also suggesting 
that we use this method to declare if we want blocking or non 
blocking writes.


No. The situation where write could (maybe) block is if the servlet 
writes in a Tomcat thread. Typically, this is the reply-later design, 
using the sleep/callback methods. The isWriteable method is not used, 
since the servlet merely wants (in that common design) to send a 
response as fast as possible, and typically this sort of response is 
not too large and unlikely to cause IO problems. This blocking 
behavior is allowed in that case to avoid forcing the user to put in 
more complex logic to deal with the partial write + event, and is set 
just for the amount of time it takes to perform the write (note that 
this ).



  At this point this method is doing three things:
  a) returns true/false if we can write data
  b) delegates a socket to the poller to write data and generate a 
event(WRITE) to the comet processor

  c) configures a write to be blocking or non blocking
  This is for sure not what I would expect of a "simple API", if 
simple means less keystrokes than yes, but simple to me also means 
intuitive and easily understood.


So you have plenty of methods to do the same thing.

Given points 1-4, this is what is going to happen to every single 
developer
 I) They are going to use stream.write and event.isWriteable all the 
time, not realizing what it actually does
II) They are going to get confused when they receive an IOException 
for trying to perform a write, cause they used isWriteable and the 
socket went into non blocking mode


If that's what you want to believe ...

At this point, this 'simple' API, obviously not so simple, instead 
it becomes very complicated, as I would almost have to reverse 
engineer the code to truly understand what it does.
It may be simple to you and me, but that is because we are 
implementing it.


I really don't see what is complex, especially when you look at the 
code the user would write for the simple cases, where you don't even 
have to use any API besides stream.write:

- reply later
- wait for read events, and write data in response to it

The complex case deals with handling incomplete async writes if you 
don't simply drop connection.


so what does this mean to 'isReadable'? That I'm automatically 
registering for a READ event if it returns false? Maybe I don't want 
a READ event, I just want to see if any data has trickled in. so if 
I call sleep(), should I then call isReadable() to reregister for 
the read. how is this simpler than that r

svn commit: r547055 - /tomcat/trunk/webapps/docs/aio.xml

[fhanik]

Author: fhanik
Date: Wed Jun 13 15:51:56 2007
New Revision: 547055

URL: http://svn.apache.org/viewvc?view=rev&rev=547055
Log:
added simple example code snippets to comet usage

Modified:
tomcat/trunk/webapps/docs/aio.xml

Modified: tomcat/trunk/webapps/docs/aio.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/aio.xml?view=diff&rev=547055&r1=547054&r2=547055
==
--- tomcat/trunk/webapps/docs/aio.xml (original)
+++ tomcat/trunk/webapps/docs/aio.xml Wed Jun 13 15:51:56 2007
@@ -151,6 +151,26 @@
 
   
   
+  
+  
+The previous section touched a little bit on the comet connection 
lifecycle. 
+It is important to remember that comet events are based around IO on an 
actual socket.
+To clarify the Comet API, it has been created to resemble the java.nio 
channel/selector APIs.
+In the case of Comet, Tomcat is the selector and using the CometEvent 
object, you can 
+register and unregister your Comet event for different event type 
notifications.
+We call the parameter to the CometEvent.register/unregister 
method a comet operation.
+This is similar to the interestOps method of a SelectionKey 
in the java.nio implementation.
+The Comet implementation of register and unregister has been greatly 
simplified to not force the 
+comet developer to implement complex synchronizations around the register 
and unregister code.
+  
+  
+It is important to realize, just like the java.nio API, that once an 
operation has been registered, it will
+remain registered until it is unregistered. If you have registered 
OP_READ, then the comet connection will
+fire READ events, every time data arrives until your unregister the 
OP_READ operation.
+OP_CALLBACK/OP_WRITE work in the same way, essentially, 
register(OP_CALLBACK|OP_WRITE) will keep spawning 
+CALLBACK/WRITE events until you unregister the operation(s).
+  
+  
 
   
   
@@ -261,8 +281,269 @@
   
   
 
-  
+  
+  
+Imagine you are writing a servlet that is updating a set of 
+stock tickers. You have a back ground thread that is receiving 
+updates for tickers as they happen, and you wish to push out these
+to all the tickers that have the stocks in their list.
+In the following example, you can accomplish maximum through put by 
+taking advantage of Tomcat's non blocking Comet features.
+When the StockUpdater thread is running, it receives a set of stock 
updates.
+It gets all the clients that are registered for the stocks that have 
changed.
+For each client, there is an associated CometEvent object, the StockUpdater
+checks if it can write without blocking, if so it writes directly, 
otherwise
+it registers the client for a WRITE event, that will tell the 
+system that we can write the data now.
+This is a perfect example of how we can take advantage of the combination 
of the write event
+and the isWriteable method to determine, when we can write the data.
+As with any kind of non blocking IO, you will need to synchronize your 
code,
+this has not been done in the example below since the focus is on the 
+data delivery, not synchronization.
+  
+  
+public class ExampleCometStockStreamer implements CometProcessor {
+  ...
+  public class StockUpdater extends Thread {
+public void run() {
+  ...
+  StockUpdates[] updates = fetchUpdates();
+  Client[] clients = getClients(updates);
+  for (int i=0; i

5.5.24 candidate binaries

[Filip Hanik - Dev Lists]

http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.24/
will let these sit to mid next week, and then we can take a vote.
feedback between now and then is welcome at any time.

Filip

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

svn commit: r547026 - /tomcat/site/tags/TOMCAT_5_5_24/

[fhanik]

Author: fhanik
Date: Wed Jun 13 13:48:36 2007
New Revision: 547026

URL: http://svn.apache.org/viewvc?view=rev&rev=547026
Log:
Tagging Tomcat version TOMCAT_5_5_24.

Added:
tomcat/site/tags/TOMCAT_5_5_24/
  - copied from r547025, tomcat/site/trunk/


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

svn commit: r547025 - /tomcat/servletapi/tags/servlet2.4-jsp2.0-tc5.x/TOMCAT_5_5_24/

[fhanik]

Author: fhanik
Date: Wed Jun 13 13:48:26 2007
New Revision: 547025

URL: http://svn.apache.org/viewvc?view=rev&rev=547025
Log:
Tagging Tomcat version TOMCAT_5_5_24.

Added:
tomcat/servletapi/tags/servlet2.4-jsp2.0-tc5.x/TOMCAT_5_5_24/
  - copied from r547024, tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/


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

svn commit: r547024 - /tomcat/jasper/tags/tc5.5.x/TOMCAT_5_5_24/

[fhanik]

Author: fhanik
Date: Wed Jun 13 13:48:16 2007
New Revision: 547024

URL: http://svn.apache.org/viewvc?view=rev&rev=547024
Log:
Tagging Tomcat version TOMCAT_5_5_24.

Added:
tomcat/jasper/tags/tc5.5.x/TOMCAT_5_5_24/
  - copied from r547023, tomcat/jasper/tc5.5.x/


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

svn commit: r547023 - /tomcat/container/tags/tc5.5.x/TOMCAT_5_5_24/

[fhanik]

Author: fhanik
Date: Wed Jun 13 13:48:06 2007
New Revision: 547023

URL: http://svn.apache.org/viewvc?view=rev&rev=547023
Log:
Tagging Tomcat version TOMCAT_5_5_24.

Added:
tomcat/container/tags/tc5.5.x/TOMCAT_5_5_24/
  - copied from r547022, tomcat/container/tc5.5.x/


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

svn commit: r547022 - /tomcat/connectors/tags/tc5.5.x/TOMCAT_5_5_24/

[fhanik]

Author: fhanik
Date: Wed Jun 13 13:47:56 2007
New Revision: 547022

URL: http://svn.apache.org/viewvc?view=rev&rev=547022
Log:
Tagging Tomcat version TOMCAT_5_5_24.

Added:
tomcat/connectors/tags/tc5.5.x/TOMCAT_5_5_24/
  - copied from r547021, tomcat/connectors/trunk/


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

svn commit: r547021 - /tomcat/build/tags/tc5.5.x/TOMCAT_5_5_24/

[fhanik]

Author: fhanik
Date: Wed Jun 13 13:47:46 2007
New Revision: 547021

URL: http://svn.apache.org/viewvc?view=rev&rev=547021
Log:
Tagging Tomcat version TOMCAT_5_5_24.

Added:
tomcat/build/tags/tc5.5.x/TOMCAT_5_5_24/
  - copied from r547020, tomcat/build/tc5.5.x/


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

Re: Proposed simplification of CometEvent

[Filip Hanik - Dev Lists]

Costin Manolache wrote:

On 6/13/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:


Costin Manolache wrote:
> For a separate opinion:
>
> In the trunk version:
> - the '...' and array return seem strange and generate GC ( not a big
> issue
> those days, but still inconsistent with the
> rest of tomcat )
yes, its a new language feature, hence it wasn't available in previous
JDKs or Tomcat.
its a vararg, if we don't want it we can switch to arrays, it works the
same way.



Yes, I know it's a vararg and my concern is not that it is not 
available in

all VMs, but
that it creates temp arrays and GC, which is inconsistent with the 
rest of

tomcat which is very careful with creating objects.
Also - it's quite useless in this particular case, printf is a good 
use case

but
that doesn't mean it should be used everywhere.

true.





> - the API seems a bit over-complex - for example, why
> setConfiguration(COMMET_BLOCKING) instead of setBlocking() ?
> I agree that it less likely to break implementations by adding to the
> enom
> instead of adding methods to the interface - not sure
> why it's not an abstract class in the first place.
if we want to simplify it, we would call it
configureBlocking(boolean) - consistent with JDK APIs :)



Sounds better - but as Remy explained you would first need to explain
why blocking is needed in this context and how to deal with the confusion
of mixing blocking and non-blocking for users, and the implementation
complexities it adds.
trunk doesn't mix them. a comet connection is either blocking or non 
blocking, it doesn't shift between the two,
and it allows developers to choose what they want. Just like a  
SocketChannel in java.nio.

there is nothing confusing about that, unless java.nio is confusing :)






> - please don't call the method configure(), it's commonly used with a
> different meaning ( i.e. setting the port or general configuration).
> setConnectionMode, etc. And using the enum doesn't sound consistent 
with

> other APIs either.
we can call it whatever we want. But saying not using enum, its not
consistent with other APIs in Tomcat,
means would never take advantage of new language features ever, I think
that would be a shame.



Same as above - the question is not about using new features, but if the
features
fit the use. I have no problem with using enums for the event types - 
just

for
configure, in the context of configure(enum) versus setBlocking(), 
setFoo().
this has been adjusted based on the feedback, the method is now 
configureBlocking(boolean)

the state of it can be used by calling isBlocking()

register is using enums, mainly cause Remy, while he was working with 
this API insisted on it.
I had preferred using an int, just like the socket API, but since Remy 
had initially agreed to register, and proposed enum and unregister

we went with that.







> - see bellow - I don't think I understand the benefits of mixing
blocking
> and non-blocking in this interface, it is quite confusing.
It would be mixing it, its a one time config, during the BEGIN event,
you say
configureBlocking(true) or configureBlocking(false).
Comet is very much connection centric, so you can't mix it.

In the trunk API, its clear to what you are using, blocking or non
blocking, in the sandbox API, the swap
of it happens when invoking isWriteable or isReadable, making the state
of the comet connection confusing to the developer.



I'm not sure it's true - my understanding is that sandbox is all
non-blocking.
Invoking isWriteable is not blocking.

I think it would be ok to add a blocking waitForEvent() - combined with
isReadable()/isWriteable()
this would be a dead lock, as the Comet API must guarantee that a 
CometProcessor.event
is only invoked by one worker thread at any time. The blocking you are 
talking about can be done
using an async thread can be done by registering for the event you wish 
to be notified in and then

maybe await a latch countdown, or doing a sync/wait() combo.

it will allow a sort-of blocking model. But having methods that are 
blocking

sometimes
and sometimes not - based on some config - is dangerous and confusing.
As I mentioned, the trunk Comet API is actually very similar to java.nio 
API, hence developers familiar with that will instantly recognize

themselves and should get comfortable with the API.

Here are some of the things that might need to be clarified about the 
trunk API:


1. It is possible to not be registered for any events, and even do 
polling for data asynchronously
2. ERROR and END events, are an exception, you cant unregister for 
those, as those might require the

  underlying socket to be closed, or has already been closed
3. I believe it to be much cleaner to follow an event model, after all 
that is what Comet is.
4. In previous emails I have questioned the usability of "non 
blocking/async" reads and writes,
  as they are not implemented to true non block unless they entire 
buffer/filter stack is modified.
  A 

Re: Proposed simplification of CometEvent

[Costin Manolache]

On 6/13/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:


Costin Manolache wrote:
>> setTimeout() is not optional (the javadoc is out of date, sorry), there
>> was an agreement on that earlier. Timeout sets the connection timeout,
>> which is most likely useful even if there are events. It's quite
>> possible sleep could use a timeout argument (I think calling setTimeout
>> is more or less mandatory when using sleep, and OTOH calling setTimout
>> is not as important otherwise).
>
> Ok - then sleep needs the extra argument, and will mean same as
> Thread.sleep(),
> but
> not-blocking ?

This sleep is a non blocking call, and instructs the connection to "do
nothing until I wake you up (or a timeout occurs, of course)".



Please add this to the javadoc :-)
And maybe call it 'setTimerEvent(timeMillis)' or something like that - to
avoid
confusion with Thread.sleep() which is blocking the thread.

IMHO it would be very nice to  also have a blocking waitForEvent(timeMillis)
-
as an alternative to adding blocking mode as in the trunk.



Although the read event indicates there's data to read, isReadable

>> indicates if it is possible to continue reading.
>
> My understanding was that the InputStream in request is used for actual
> reading -
> and available() could do the same thing. What is the difference then
> between
> the 2 ?

isReadable is the same as is.available (and reader.ready). It's there
for a bit of symmetry after adding isWriteable, which may or may not be
useful, and I didn't care about it.



Why not call it available() and return the same as the servlet method ? I
think
it's ok to have 'shortcuts' in the CometEvent - even read()/write() methods
that
would expose more efficient ways to send/get data than the InputStream.



isWriteable indicates if the last write operation managed to write more
>> than 0 bytes. If the last write wrote 0, then isWriteable will return
>> false, so the servlet knows it should stop writing on this connection
>> for now (since it cannot accept any output at the moment). Later on,
the
>> servlet will receive a write event, and can resume writing.
>
> I'm still a bit confused about this - my understanding was that write
event
> means the
> previous buffers were written, and you can write more. There are some
> buffers
> on the OS side as well as buffers on the connector side.

Yes, it means that: the servlet gets a write event, which means it can
start writing again.

> What do you mean by 'managed to write more than 0 bytes' - the write in
the
> OutputStream
> can go to some of the buffers, or to the client. I assume you don't mean
> the
> client ( due to TCP
> delays ).

I was talking about the actual write on the socket (in APR, it's done in
InternalAprOutputBuffer.flushBuffer), which may return 0. At the servlet
layer, as per the contract of the OutputStream API, is must write
everything or fail, and this isn't going to change.



Where 'write everything' means 'maybe buffer some of it at OS or java
layer'.

Could you add more javadocs on how much can you expect to write if
isWriteable() returns
true ? Since the OutputStream method doesn't support partial writes - I
suppose
this would help more than isWriteable.




- If doing synchronous writes inside some event (either a read or

>> callback event, most likely), then both blocking and non blocking mode
>> make sense. Some servlets may prefer to use blocking mode although it
>> could be holding a thread for a while (for example if the idea is only
>
> maybe a 'waitForEvent()' method to allow a servlet to block if he wants
> to ?
>
> Or is sleep() supposed to do this - I'm not sure from the comments if
> sleep() will
> block or just triger an event when the interval expires ?

Sleep will by itself only trigger timeout events (the method call itself
will return immediately). The servlet can use the callback method to
trigger an event before the timeout occurs.

> You mean sort of 'notify()' -  i.e. someone calls callback() and will
> trigger the
> servlet to be executed, interrupting any sleep or wait ?

Originally, this was indeed supposed to be called "notify", but it's not
possible due to Object.notify :( If you have another name to suggest to
  replace "callback" ...



Well - servletNotify() or servletWakeup() or sendCometEvent() ?

Costin


In general ( both versions):

>> > - it would be great to move it from o.a.catalina to org.apache.comet
>>
>> It's a possibility.
>
> I think more comments and examples ( and maybe better names ) would be
> great.

I think there's going to be some code using Comet soon.

Rémy

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

Re: Proposed simplification of CometEvent

[Costin Manolache]

On 6/13/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:


Costin Manolache wrote:
> For a separate opinion:
>
> In the trunk version:
> - the '...' and array return seem strange and generate GC ( not a big
> issue
> those days, but still inconsistent with the
> rest of tomcat )
yes, its a new language feature, hence it wasn't available in previous
JDKs or Tomcat.
its a vararg, if we don't want it we can switch to arrays, it works the
same way.



Yes, I know it's a vararg and my concern is not that it is not available in
all VMs, but
that it creates temp arrays and GC, which is inconsistent with the rest of
tomcat which is very careful with creating objects.
Also - it's quite useless in this particular case, printf is a good use case
but
that doesn't mean it should be used everywhere.




> - the API seems a bit over-complex - for example, why
> setConfiguration(COMMET_BLOCKING) instead of setBlocking() ?
> I agree that it less likely to break implementations by adding to the
> enom
> instead of adding methods to the interface - not sure
> why it's not an abstract class in the first place.
if we want to simplify it, we would call it
configureBlocking(boolean) - consistent with JDK APIs :)



Sounds better - but as Remy explained you would first need to explain
why blocking is needed in this context and how to deal with the confusion
of mixing blocking and non-blocking for users, and the implementation
complexities it adds.




> - please don't call the method configure(), it's commonly used with a
> different meaning ( i.e. setting the port or general configuration).
> setConnectionMode, etc. And using the enum doesn't sound consistent with
> other APIs either.
we can call it whatever we want. But saying not using enum, its not
consistent with other APIs in Tomcat,
means would never take advantage of new language features ever, I think
that would be a shame.



Same as above - the question is not about using new features, but if the
features
fit the use. I have no problem with using enums for the event types - just
for
configure, in the context of configure(enum) versus setBlocking(), setFoo().





> - see bellow - I don't think I understand the benefits of mixing
blocking
> and non-blocking in this interface, it is quite confusing.
It would be mixing it, its a one time config, during the BEGIN event,
you say
configureBlocking(true) or configureBlocking(false).
Comet is very much connection centric, so you can't mix it.

In the trunk API, its clear to what you are using, blocking or non
blocking, in the sandbox API, the swap
of it happens when invoking isWriteable or isReadable, making the state
of the comet connection confusing to the developer.



I'm not sure it's true - my understanding is that sandbox is all
non-blocking.
Invoking isWriteable is not blocking.

I think it would be ok to add a blocking waitForEvent() - combined with
isReadable()/isWriteable()
it will allow a sort-of blocking model. But having methods that are blocking
sometimes
and sometimes not - based on some config - is dangerous and confusing.

Costin

Filip

>
> In the sandbox version:
> - sleep() and setTimeout(int) -> why not sleep(int millis) ? I think
it's
> confusing to have both and the interactions between them, in
> particular setTimeout is marked optional ? It makes sense to have
> setTimeout() as a general timeout.
>
> - not sure I understand the use case for isReadable()/isWriteable() -
> when
> will this be called ? My understanding was that when
> the connection is readable, a callback will be generated with
> EventType ==
> READ. Also it's very confusing to mix the 'blocking' in the
> isReadable()/isWriteable() - it would be much cleaner to say that the
> connection is always non-blocking, and add a method to switch to
blocking
> mode ( then use the regular servlet methods maybe ). Using the
> ComentEvent
> for both is IMHO dangerous.
>
> - will sleep() still allow callbacks ( and if not - what will happen
with
> them )? What's going to happen with callbacks if callback() is not
> called ?
>
>
> In general ( both versions):
> - it would be great to move it from o.a.catalina to org.apache.comet
>
> Costin
>
> On 6/11/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
>>
>> Filip Hanik - Dev Lists wrote:
>> > Ok, let me see if I can summarize.
>> >
>> > 1. Whether you write out the stored buffer using the Poller thread,
>> or a
>> > Tomcat worker thread (flushed in Http11xxxProcessor) as described
>> below
>> > I originally thought of this as async write, as we are simply doing a
>> > write with another one of our threads. Originally when we were
talking
>> > non blocking writes, I was thinking along the lines of non blocking
to
>> > where the Comet developer had to do that logic, just as he was
>> writing a
>> > socket, possibly like (but not suggested) a
>> > CometEvent.nonBlockWrite(ByteBuffer).
>> >
>> > 2. Do we need non blocking? with the methods of isWriteable and the
>> > ability to register(OP_WRITE)->event

svn commit: r546999 - in /tomcat/trunk/java/org/apache: catalina/CometEvent.java catalina/connector/CometEventImpl.java coyote/ActionCode.java coyote/http11/Http11NioProcessor.java

[fhanik]

Author: fhanik
Date: Wed Jun 13 11:51:38 2007
New Revision: 546999

URL: http://svn.apache.org/viewvc?view=rev&rev=546999
Log:
simplify API a bit based on feedback

Modified:
tomcat/trunk/java/org/apache/catalina/CometEvent.java
tomcat/trunk/java/org/apache/catalina/connector/CometEventImpl.java
tomcat/trunk/java/org/apache/coyote/ActionCode.java
tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java

Modified: tomcat/trunk/java/org/apache/catalina/CometEvent.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/CometEvent.java?view=diff&rev=546999&r1=546998&r2=546999
==
--- tomcat/trunk/java/org/apache/catalina/CometEvent.java (original)
+++ tomcat/trunk/java/org/apache/catalina/CometEvent.java Wed Jun 13 11:51:38 
2007
@@ -163,44 +163,28 @@
 public void setTimeout(int timeout)
 throws ServletException, UnsupportedOperationException;
 
-
-
-/**
- * Enumeration for a comet connection state.
- * A comet session can be blocking or non blocking.
- * COMET_NON_BLOCKING
- * Option bit set for allowing non blocking IO
- * when reading from the request or writing to the response
- * COMET_BLOCKING
- * Configure the comet connection for blocking IO, this is the default 
setting
- * 
- * @see #configure(int)
- */
-public enum CometConfiguration {COMET_BLOCKING, COMET_NON_BLOCKING};
-
+
 /**
  * Configures the connection for desired IO options.
  * By default a Comet connection is configured for 
  * a) Blocking IO - standard servlet usage
  * b) Register for READ events when data arrives
  * Tomcat Comet allows you to configure for additional options:
- * the COMET_NON_BLOCKING bit signals whether writing and 
reading from the request 
+ * the configureBlocking(false) bit signals whether writing 
and reading from the request 
  * or writing to the response will be non blocking.
- * the COMET_BLOCKING bit signals the container you wish for 
read and write to be done in a blocking fashion
- * @param cometOptions int - the option bit set
+ * the configureBlocking(true) bit signals the container you 
wish for read and write to be done in a blocking fashion
+ * @param blocking - true to make read and writes blocking
  * @throws IllegalStateException - if this method is invoked outside of 
the BEGIN event
- * @see #CometConfiguration
  * @see #isReadable()
  * @see #isWriteable()
  */
-public void configure(CometConfiguration... options) throws 
IllegalStateException;
+public void configureBlocking(boolean blocking) throws 
IllegalStateException;
 
 /**
  * Returns the configuration for this Comet connection
- * @return CometConfiguration[]
- * @see #configure(CometConfiguration...)
+ * @return true if the connection is configured to be blocking, false for 
non blocing
  */
-public CometConfiguration[] getConfiguration();
+public boolean isBlocking();
 
 /**
  * OP_CALLBACK - receive a CALLBACK event from the container

Modified: tomcat/trunk/java/org/apache/catalina/connector/CometEventImpl.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CometEventImpl.java?view=diff&rev=546999&r1=546998&r2=546999
==
--- tomcat/trunk/java/org/apache/catalina/connector/CometEventImpl.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/connector/CometEventImpl.java Wed Jun 
13 11:51:38 2007
@@ -29,6 +29,7 @@
 import org.apache.catalina.util.StringManager;
 import org.apache.coyote.ActionCode;
 import org.apache.tomcat.util.net.PollerInterest;
+import org.apache.tomcat.util.MutableBoolean;
 
 public class CometEventImpl implements CometEvent {
 
@@ -79,9 +80,9 @@
 protected HashSet cometOperations = new 
HashSet(3);
 
 /**
- * Current set of configurations
+ * Blocking or not blocking
  */
-protected HashSet cometConfigurations = new 
HashSet(3);
+protected boolean blocking = true;
 
 protected WorkerThreadCheck threadCheck = new WorkerThreadCheck();
 
@@ -95,7 +96,7 @@
 public void clear() {
 request = null;
 response = null;
-cometConfigurations.clear();
+blocking = true;
 cometOperations.clear();
 }
 
@@ -151,13 +152,12 @@
 return cometOperations.contains(op);
 }
 
-public void configure(CometEvent.CometConfiguration... options) throws 
IllegalStateException {
+public void configureBlocking(boolean blocking) throws 
IllegalStateException {
 checkWorkerThread();
-cometConfigurations.clear();
-for (CometEvent.CometConfiguration cc : options) {
-cometConfigurations.add(cc);
-}
-request.action(ActionCode.ACTION_COMET_CONFIGUR

Re: Proposed simplification of CometEvent

[Filip Hanik - Dev Lists]

Costin Manolache wrote:

For a separate opinion:

In the trunk version:
- the '...' and array return seem strange and generate GC ( not a big 
issue

those days, but still inconsistent with the
rest of tomcat )
yes, its a new language feature, hence it wasn't available in previous 
JDKs or Tomcat.
its a vararg, if we don't want it we can switch to arrays, it works the 
same way.


- the API seems a bit over-complex - for example, why
setConfiguration(COMMET_BLOCKING) instead of setBlocking() ?
I agree that it less likely to break implementations by adding to the 
enom

instead of adding methods to the interface - not sure
why it's not an abstract class in the first place.

if we want to simplify it, we would call it
configureBlocking(boolean) - consistent with JDK APIs :)


- please don't call the method configure(), it's commonly used with a
different meaning ( i.e. setting the port or general configuration).
setConnectionMode, etc. And using the enum doesn't sound consistent with
other APIs either.
we can call it whatever we want. But saying not using enum, its not 
consistent with other APIs in Tomcat,
means would never take advantage of new language features ever, I think 
that would be a shame.


- see bellow - I don't think I understand the benefits of mixing blocking
and non-blocking in this interface, it is quite confusing.
It would be mixing it, its a one time config, during the BEGIN event, 
you say

configureBlocking(true) or configureBlocking(false).
Comet is very much connection centric, so you can't mix it.

In the trunk API, its clear to what you are using, blocking or non 
blocking, in the sandbox API, the swap
of it happens when invoking isWriteable or isReadable, making the state 
of the comet connection confusing to the developer.


Filip


In the sandbox version:
- sleep() and setTimeout(int) -> why not sleep(int millis) ? I think it's
confusing to have both and the interactions between them, in
particular setTimeout is marked optional ? It makes sense to have
setTimeout() as a general timeout.

- not sure I understand the use case for isReadable()/isWriteable() - 
when

will this be called ? My understanding was that when
the connection is readable, a callback will be generated with 
EventType ==

READ. Also it's very confusing to mix the 'blocking' in the
isReadable()/isWriteable() - it would be much cleaner to say that the
connection is always non-blocking, and add a method to switch to blocking
mode ( then use the regular servlet methods maybe ). Using the 
ComentEvent

for both is IMHO dangerous.

- will sleep() still allow callbacks ( and if not - what will happen with
them )? What's going to happen with callbacks if callback() is not 
called ?



In general ( both versions):
- it would be great to move it from o.a.catalina to org.apache.comet

Costin

On 6/11/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:


Filip Hanik - Dev Lists wrote:
> Ok, let me see if I can summarize.
>
> 1. Whether you write out the stored buffer using the Poller thread, 
or a
> Tomcat worker thread (flushed in Http11xxxProcessor) as described 
below

> I originally thought of this as async write, as we are simply doing a
> write with another one of our threads. Originally when we were talking
> non blocking writes, I was thinking along the lines of non blocking to
> where the Comet developer had to do that logic, just as he was 
writing a

> socket, possibly like (but not suggested) a
> CometEvent.nonBlockWrite(ByteBuffer).
>
> 2. Do we need non blocking? with the methods of isWriteable and the
> ability to register(OP_WRITE)->event(WRITE), if the number of bytes 
you

> write is usually smaller than the socket buffer, chances are that most
> writes will be non blocking. I would even argue a large majority would
> be non blocking, and thus the implementation or the complexity thereof
> would not be needed. And with the ability to do async writes, means I
> can create my own thread pool/write queue to perform these writes.

You are writing the opposite thing to the previous email, and we are
back to "non blocking is useless". The problem is that I understand
blocking IO as "write this data, and return when it's done". If the
socket is in blocking mode, any write done by the servlet may block,
regardless of what isWriteable says. Of course, it's very unlikely,
which is why Comet in 6.0.x works.

> 3. isWriteable - simple method, but I don't like that the method in
> itself performs actions like adding the socket to a poller etc.
>   Instead isWriteable==true means that you can write on the socket,
> isWriteable==false you cannot. This method should be able to be 
invoked
> as many times as its wanted, and is thread safe and doesn't do 
anything

> funky underneath.

Ok, so you prefer a more complex API (if I follow "just in case it was
useful"). I started with an API which would expose all operations, and
looked into removing what was not explicitly useful.

> 4. isWriteable - I'm also reading in that you a

DO NOT REPLY [Bug 42650] - PooledParallelSender.sendMessage throws NullpointerException

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-06-13 10:14 ---
Thanks for the bug report, 
consider increasing your sender pool, or find out why you are running out of
them, or you can send messages asynchrously

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]

svn commit: r546959 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java

[fhanik]

Author: fhanik
Date: Wed Jun 13 10:07:06 2007
New Revision: 546959

URL: http://svn.apache.org/viewvc?view=rev&rev=546959
Log:
fix for BZ 42650
http://issues.apache.org/bugzilla/show_bug.cgi?id=42650

Modified:

tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java?view=diff&rev=546959&r1=546958&r2=546959
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
 (original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
 Wed Jun 13 10:07:06 2007
@@ -44,12 +44,18 @@
 public void sendMessage(Member[] destination, ChannelMessage message) 
throws ChannelException {
 if ( !connected ) throw new ChannelException("Sender not connected.");
 ParallelNioSender sender = (ParallelNioSender)getSender();
-try {
-sender.sendMessage(destination, message);
-sender.keepalive();
-}finally {
-if ( !connected ) disconnect();
-returnSender(sender);
+if (sender == null) {
+ChannelException cx = new ChannelException("Unable to retrieve a 
data sender, time out error.");
+for (int i = 0; i < destination.length; i++) 
cx.addFaultyMember(destination[i], new NullPointerException("Unable to retrieve 
a sender from the sender pool"));
+throw cx;
+} else {
+try {
+sender.sendMessage(destination, message);
+sender.keepalive();
+} finally {
+if (!connected) disconnect();
+returnSender(sender);
+}
 }
 }
 



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

svn commit: r546958 - /tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java

[fhanik]

Author: fhanik
Date: Wed Jun 13 10:05:14 2007
New Revision: 546958

URL: http://svn.apache.org/viewvc?view=rev&rev=546958
Log:
fix for BZ 42650
http://issues.apache.org/bugzilla/show_bug.cgi?id=42650


Modified:

tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java?view=diff&rev=546958&r1=546957&r2=546958
==
--- 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
 (original)
+++ 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
 Wed Jun 13 10:05:14 2007
@@ -44,12 +44,18 @@
 public void sendMessage(Member[] destination, ChannelMessage message) 
throws ChannelException {
 if ( !connected ) throw new ChannelException("Sender not connected.");
 ParallelNioSender sender = (ParallelNioSender)getSender();
-try {
-sender.sendMessage(destination, message);
-sender.keepalive();
-}finally {
-if ( !connected ) disconnect();
-returnSender(sender);
+if (sender == null) {
+ChannelException cx = new ChannelException("Unable to retrieve a 
data sender, time out error.");
+for (int i = 0; i < destination.length; i++) 
cx.addFaultyMember(destination[i], new NullPointerException("Unable to retrieve 
a sender from the sender pool"));
+throw cx;
+} else {
+try {
+sender.sendMessage(destination, message);
+sender.keepalive();
+} finally {
+if (!connected) disconnect();
+returnSender(sender);
+}
 }
 }
 



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

DO NOT REPLY [Bug 42648] - SWAP increases by the cluster of Tomca6

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-06-13 10:01 ---
Basically, using allocateDirect, uses memory outside of your -Xmx and -Xms,
since your Java heap(-Xmx) is so high, you have not left enough room for the
direct memory. This is part of the Java memory model.
However, you have discovered an optimization, that we don't need to create a new
buffer and wait for GC to clean out the old one.

So thanks for the notification, and remember that allocateDirect is memory
outside of -Xmx memory space.

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]

svn commit: r546955 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java

[fhanik]

Author: fhanik
Date: Wed Jun 13 10:00:21 2007
New Revision: 546955

URL: http://svn.apache.org/viewvc?view=rev&rev=546955
Log:
fix for BZ 42648
http://issues.apache.org/bugzilla/show_bug.cgi?id=42648

Modified:

tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java?view=diff&rev=546955&r1=546954&r2=546955
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
 (original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
 Wed Jun 13 10:00:21 2007
@@ -63,12 +63,15 @@
 
 // loop forever waiting for work to do
 public synchronized void run() { 
-if ( (getOptions() & OPTION_DIRECT_BUFFER) == OPTION_DIRECT_BUFFER ) {
-buffer = ByteBuffer.allocateDirect(getRxBufSize());
-}else {
-buffer = ByteBuffer.allocate (getRxBufSize());
+if ( buffer == null ) {
+if ( (getOptions() & OPTION_DIRECT_BUFFER) == 
OPTION_DIRECT_BUFFER) {
+buffer = ByteBuffer.allocateDirect(getRxBufSize());
+} else {
+buffer = ByteBuffer.allocate(getRxBufSize());
+}
+} else {
+buffer.clear();
 }
-
 if (key == null) {
 return;// just in case
 }



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

svn commit: r546952 - /tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java

[fhanik]

Author: fhanik
Date: Wed Jun 13 09:55:27 2007
New Revision: 546952

URL: http://svn.apache.org/viewvc?view=rev&rev=546952
Log:
Fix for BZ 42648
http://issues.apache.org/bugzilla/show_bug.cgi?id=42648

Modified:

tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java?view=diff&rev=546952&r1=546951&r2=546952
==
--- 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
 (original)
+++ 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
 Wed Jun 13 09:55:27 2007
@@ -63,12 +63,15 @@
 
 // loop forever waiting for work to do
 public synchronized void run() { 
-if ( (getOptions() & OPTION_DIRECT_BUFFER) == OPTION_DIRECT_BUFFER ) {
-buffer = ByteBuffer.allocateDirect(getRxBufSize());
-}else {
-buffer = ByteBuffer.allocate (getRxBufSize());
+if ( buffer == null ) {
+if ( (getOptions() & OPTION_DIRECT_BUFFER) == 
OPTION_DIRECT_BUFFER) {
+buffer = ByteBuffer.allocateDirect(getRxBufSize());
+} else {
+buffer = ByteBuffer.allocate(getRxBufSize());
+}
+} else {
+buffer.clear();
 }
-
 if (key == null) {
 return;// just in case
 }



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

Re: svn commit: r544401 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java webapps/docs/changelog.xml webapps/docs/monitoring.xml

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
My changes to the AJP Connectors are pretty much harmless for anything 
that currently works.  Tomcat will do exactly the same thing it always 
has unless the request body is over 2GB.  Currently, mod_jk can't 
handle this case anyway, and the reporter of BZ 42608 claims that 
mod_proxy_ajp can't either (but I can't see it myself).  However, if 
you feel strongly about it, it is always your right to veto the 
commits :).
  

we're good, I'll tag later today


The patch does look good to me, and should probably be merged to all 
other branches.


Rémy

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

Tagging 5.5.24

[Filip Hanik - Dev Lists]

in about 2-4  hours

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

Re: svn commit: r544401 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java webapps/docs/changelog.xml webapps/docs/monitoring.xml

[Filip Hanik - Dev Lists]

Bill Barker wrote:
"Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
  

Bill Barker wrote:

"Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]


  
so if we are not going to build the class, why would we include it in 
SVN and document it? It wont be part of the release.




As has been going on in Jakarta-Commons, the release is the source 
release. The binary is just gravy:).  The Connectors tree already (for a 
very long time), has conditional dependancies on the JDK used to compile.


  

got it. then yes add it in...later :)

once I announced that the tag would be created, a pile of checkins 
suddenly happened, and not properly tested.

I'd rather see those checkins for after the tag.

reasonable?



My changes to the AJP Connectors are pretty much harmless for anything that 
currently works.  Tomcat will do exactly the same thing it always has unless 
the request body is over 2GB.  Currently, mod_jk can't handle this case 
anyway, and the reporter of BZ 42608 claims that mod_proxy_ajp can't either 
(but I can't see it myself).  However, if you feel strongly about it, it is 
always your right to veto the commits :).
  

we're good, I'll tag later today
  
Filip 






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

Re: svn commit: r546531 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_global.h common/jk_url.c common/jk_url.h common/list.mk.in

[Remy Maucherat]

Mladen Turk wrote:

That's why I suggested to stop for a while and see all the possibilities.


We've talked about it for a while (see the length of this thread ...), 
and I consider it is time to think over code: apply the proposed patch 
which aims to harmonize with mod_proxy, and see what actual problems it 
causes, if any. This means I am vetoing r544137 (the patch was an 
emergency fix with some side effects, and needs to be replaced with a 
proper implementation).


Rémy

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

Re: svn commit: r546531 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_global.h common/jk_url.c common/jk_url.h common/list.mk.in

[Mladen Turk]

Remy Maucherat wrote:

Mladen Turk wrote:

Why?
Let's stop a bit and test things before.


Jean-Frédéric proposes implementing the same behavior as mod_proxy, so I
don't see how this can be a bad thing.


First of all I didn't said it's a bad thing or anything like that.
We need the same behavior on Apache and IIS (at least), so this patch
needs to be tested on IIS and Netscape as well.
Also I think we should consider and discuss do we really need
extra directive or it can be done by using existing or default.

That's why I suggested to stop for a while and see all the possibilities.

Regards,
Mladen.


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

Re: svn commit: r546531 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_global.h common/jk_url.c common/jk_url.h common/list.mk.in

[Remy Maucherat]

Mladen Turk wrote:

Why?
Let's stop a bit and test things before.


Jean-Frédéric has of course done extended testing before proposing this 
:) The original patch was meant to close the "security problem" as soon 
as possible, but in the end has a bad behavior and should be reverted. 
Jean-Frédéric proposes implementing the same behavior as mod_proxy, so I 
don't see how this can be a bad thing.


Rémy

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

Re: Proposed simplification of CometEvent

[Jean-Frederic]

On Wed, 2007-06-13 at 12:04 +0200, Remy Maucherat wrote:
> Costin Manolache wrote:
> >> setTimeout() is not optional (the javadoc is out of date, sorry), there
> >> was an agreement on that earlier. Timeout sets the connection timeout,
> >> which is most likely useful even if there are events. It's quite
> >> possible sleep could use a timeout argument (I think calling setTimeout
> >> is more or less mandatory when using sleep, and OTOH calling setTimout
> >> is not as important otherwise).
> > 
> > Ok - then sleep needs the extra argument, and will mean same as 
> > Thread.sleep(),
> > but
> > not-blocking ?
> 
> This sleep is a non blocking call, and instructs the connection to "do 
> nothing until I wake you up (or a timeout occurs, of course)".

may be sleep is not the right name... Would suspend be a better name?

Cheers
Jean-Frederic


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

Re: Proposed simplification of CometEvent

[Remy Maucherat]

Costin Manolache wrote:

setTimeout() is not optional (the javadoc is out of date, sorry), there
was an agreement on that earlier. Timeout sets the connection timeout,
which is most likely useful even if there are events. It's quite
possible sleep could use a timeout argument (I think calling setTimeout
is more or less mandatory when using sleep, and OTOH calling setTimout
is not as important otherwise).


Ok - then sleep needs the extra argument, and will mean same as 
Thread.sleep(),

but
not-blocking ?


This sleep is a non blocking call, and instructs the connection to "do 
nothing until I wake you up (or a timeout occurs, of course)".



Although the read event indicates there's data to read, isReadable
indicates if it is possible to continue reading.


My understanding was that the InputStream in request is used for actual
reading -
and available() could do the same thing. What is the difference then 
between

the 2 ?


isReadable is the same as is.available (and reader.ready). It's there 
for a bit of symmetry after adding isWriteable, which may or may not be 
useful, and I didn't care about it.



isWriteable indicates if the last write operation managed to write more

than 0 bytes. If the last write wrote 0, then isWriteable will return
false, so the servlet knows it should stop writing on this connection
for now (since it cannot accept any output at the moment). Later on, the
servlet will receive a write event, and can resume writing.


I'm still a bit confused about this - my understanding was that write event
means the
previous buffers were written, and you can write more. There are some
buffers
on the OS side as well as buffers on the connector side.


Yes, it means that: the servlet gets a write event, which means it can 
start writing again.



What do you mean by 'managed to write more than 0 bytes' - the write in the
OutputStream
can go to some of the buffers, or to the client. I assume you don't mean 
the

client ( due to TCP
delays ).


I was talking about the actual write on the socket (in APR, it's done in 
InternalAprOutputBuffer.flushBuffer), which may return 0. At the servlet 
layer, as per the contract of the OutputStream API, is must write 
everything or fail, and this isn't going to change.



- If doing synchronous writes inside some event (either a read or
callback event, most likely), then both blocking and non blocking mode
make sense. Some servlets may prefer to use blocking mode although it
could be holding a thread for a while (for example if the idea is only


maybe a 'waitForEvent()' method to allow a servlet to block if he wants 
to ?


Or is sleep() supposed to do this - I'm not sure from the comments if
sleep() will
block or just triger an event when the interval expires ?


Sleep will by itself only trigger timeout events (the method call itself 
will return immediately). The servlet can use the callback method to 
trigger an event before the timeout occurs.



You mean sort of 'notify()' -  i.e. someone calls callback() and will
trigger the
servlet to be executed, interrupting any sleep or wait ?


Originally, this was indeed supposed to be called "notify", but it's not 
possible due to Object.notify :( If you have another name to suggest to 
 replace "callback" ...



In general ( both versions):
> - it would be great to move it from o.a.catalina to org.apache.comet

It's a possibility.


I think more comments and examples ( and maybe better names ) would be
great.


I think there's going to be some code using Comet soon.

Rémy

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

DO NOT REPLY [Bug 42650] New: - PooledParallelSender.sendMessage throws NullpointerException

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

   Summary: PooledParallelSender.sendMessage throws
NullpointerException
   Product: Tomcat 6
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


org.apache.catalina.tribes.transport.PooledSender.getSender() has the 
possibility of returning Null. 
However, 
org.apache.catalina.tribes.transport.nio.PooledParallelSender.sendMessage 
doesn't check Null. 
(PooledParallelSender.sendMessage calls getSender())
Therefore, NullpointerException is thrown. 
Finally, NullpointerException is thrown in the finally block. 

The following are the stack traces. 

org.apache.catalina.tribes.ChannelException: java.lang.NullPointerException; 
No faulty members identified.
at org.apache.catalina.tribes.group.GroupChannel.send
(GroupChannel.java:225)
at org.apache.catalina.tribes.group.GroupChannel.send
(GroupChannel.java:175)
at org.apache.catalina.ha.tcp.SimpleTcpCluster.send
(SimpleTcpCluster.java:835)
at org.apache.catalina.ha.tcp.SimpleTcpCluster.sendClusterDomain
(SimpleTcpCluster.java:814)
at org.apache.catalina.ha.tcp.ReplicationValve.send
(ReplicationValve.java:551)
at org.apache.catalina.ha.tcp.ReplicationValve.sendMessage
(ReplicationValve.java:535)
at 
org.apache.catalina.ha.tcp.ReplicationValve.sendSessionReplicationMessage
(ReplicationValve.java:517)
at org.apache.catalina.ha.tcp.ReplicationValve.sendReplicationMessage
(ReplicationValve.java:428)
at org.apache.catalina.ha.tcp.ReplicationValve.invoke
(ReplicationValve.java:362)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:261)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
at org.apache.jk.common.ChannelSocket.processConnection
(ChannelSocket.java:697)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt
(ChannelSocket.java:889)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:686)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException
at org.apache.catalina.tribes.transport.PooledSender.returnSender
(PooledSender.java:48)
at 
org.apache.catalina.tribes.transport.nio.PooledParallelSender.sendMessage
(PooledParallelSender.java:52)
at org.apache.catalina.tribes.transport.ReplicationTransmitter.sendMessage
(ReplicationTransmitter.java:80)
at org.apache.catalina.tribes.group.ChannelCoordinator.sendMessage
(ChannelCoordinator.java:78)
at org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage
(ChannelInterceptorBase.java:75)
at 
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.sendMessage
(TcpFailureDetector.java:87)
at org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage
(ChannelInterceptorBase.java:75)
at 
org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor.sendMe
ssage(MessageDispatchInterceptor.java:73)
at org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage
(ChannelInterceptorBase.java:75)
at org.apache.catalina.tribes.group.GroupChannel.send
(GroupChannel.java:216)


When Sender cannot be acquired, it is necessary to throw ChannelException.
Otherwise, because the exception can not catch with interceptor such as 
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector, 
the exception handling cannot be done. 
The same processing of 
org.apache.catalina.tribes.transport.bio.PooledMultiSender checks Null.

-- 
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 42648] - SWAP increases by the cluster of Tomca6

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-13 02:11 ---
Created an attachment (id=20337)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20337&action=view)
normal cases

normal cases. 

-- 
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 42648] - SWAP increases by the cluster of Tomca6

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-13 02:09 ---
Created an attachment (id=20336)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20336&action=view)
abnormal cases

abnormal cases. 


-- 
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 42648] New: - SWAP increases by the cluster of Tomca6

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

   Summary: SWAP increases by the cluster of Tomca6
   Product: Tomcat 6
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: trivial
  Priority: P4
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


SWAP increases by the cluster of Tomca6 and operation becomes unstable. 

Environment
 Tomcat6.0.13
 JDK1.5.11
 memory : 2G
 Heap size : - Xmx1500m -Xms1500m

SWAP increases only for direct="true". 
It occurs when operating for a long time by a high load. 

   

SWAP doesn't increase when setting it to direct ="false". 

   

I noticed the following. 
In org.apache.catalina.tribes.transport.nio.NioReplicationTask,buffer is made 
per run method.

public synchronized void run() { 
if ( (getOptions() & OPTION_DIRECT_BUFFER) == OPTION_DIRECT_BUFFER ) {
buffer = ByteBuffer.allocateDirect(getRxBufSize());
}else {
buffer = ByteBuffer.allocate (getRxBufSize());
}

if (key == null) {
return; // just in case
}


The buffer is enough if made once. 

For instance,
The creating of buffer by the run method is stopped. 

public synchronized void run() { 
//  if ( (getOptions() & OPTION_DIRECT_BUFFER) == OPTION_DIRECT_BUFFER ) {
//buffer = ByteBuffer.allocateDirect(getRxBufSize());
//}else {
//buffer = ByteBuffer.allocate (getRxBufSize());
//}


Creating of buffer by the setRxBufSize method.

public void setRxBufSize(int rxBufSize) {
this.rxBufSize = rxBufSize;
if ( (getOptions() & OPTION_DIRECT_BUFFER) == OPTION_DIRECT_BUFFER ) {
buffer = ByteBuffer.allocateDirect(getRxBufSize());
}else {
buffer = ByteBuffer.allocate (getRxBufSize());
}
}

Result.
SWAP doesn't increase.

-- 
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: svn commit: r546531 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_global.h common/jk_url.c common/jk_url.h common/list.mk.in

[Jean-Frederic]

On Tue, 2007-06-12 at 19:50 +0200, Mladen Turk wrote:
> Jean-Frederic wrote:
>  >>> Add ForwardURIProxy to the URl handling option.
>  >>> common/jk_url.c is just a porting of the routines
>  >>> from proxy_util.c (Apache httpd).
>  >> After quite a few discussions, I think this should be the only mode 
> available for URI handling, as the two others are broken.
>  >>
>  >> Comments ?
>  >
>  > Additionaly I want to rollback r544137 too.
>  >
> 
> Why?

To reach the following:
url   file/dir TC Compat Proxy Proxy-r544137
%252007%2007   ok no okok
%252E%252E %2E%2E  ok no nook

Of course using Compat-r544137 would reopen the vulnerability.

Cheers

Jean-Frederic


> Let's stop a bit and test things before.
> 
> Regards,
> Mladen.
> 
> 
> -
> 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]