DO NOT REPLY [Bug 18895] - Can not use HttpsURLConnection with Java 1.4.1 and Coyote/JK2 Connector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18895. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18895 Can not use HttpsURLConnection with Java 1.4.1 and Coyote/JK2 Connector --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 06:26 --- It seems that since at least 4.1.25, Tomcat has stopped initializing java.protocol.handler.pkgs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19245] - pageEncoding in static included file don't affect properly file from which is included
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19245. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19245 pageEncoding in static included file don't affect properly file from which is included [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 06:39 --- I think that JSP spec only care about the encoding of input(HTTPRequest)/output (HTTPResponse). And the encoding of the JSP file itself should be treated as system default encoding unless it has specified as following. xml encoding=HERE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19245] - pageEncoding in static included file don't affect properly file from which is included
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19245. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19245 pageEncoding in static included file don't affect properly file from which is included [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 07:11 --- You are 100% wrong. The pageEncoding is specified to default to the content- type encoding, which defaults to iso-latin-1. Please do me the courtesy of actually reading the JSP spec before wasting my time expounding your wild theories. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23105] - JkMount overrides Alias
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23105. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23105 JkMount overrides Alias --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 07:57 --- Did you tried with latest JK release (HEAD or to be released 1.2.5) ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
REMOVE MY EMAIL !!!
Calvin CoiThienThai.Com's Webmaster * Coi Thien Thai Entertainment Network http://www.coithienthai.com E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 12, 2003 1:57 AM Subject: DO NOT REPLY [Bug 23105] - JkMount overrides Alias DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23105. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23105 JkMount overrides Alias --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 07:57 --- Did you tried with latest JK release (HEAD or to be released 1.2.5) ? - 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: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
On 12 Sep 2003, [EMAIL PROTECTED] wrote:
+++ PoolTcpEndpoint.java 12 Sep 2003 03:51:36 - 1.16
@@ -389,12 +389,12 @@
if (accepted != null) {
try {
accepted.close();
-accepted = null;
} catch(Exception ex) {
msg = sm.getString(endpoint.err.nonfatal,
accepted, ex);
log.warn(msg, ex);
}
+accepted = null;
}
if( ! running ) return null;
wouldn't it be better to put the accepted = null into a finally
block so you clean up even in the (unlikely but possible) case where
close throws an Error (or Throwable) instead of an Exception?
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
- Original Message -
From: Stefan Bodewig [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, September 12, 2003 12:58 AM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
PoolTcpEndpoint.java
On 12 Sep 2003, [EMAIL PROTECTED] wrote:
+++ PoolTcpEndpoint.java 12 Sep 2003 03:51:36 - 1.16
@@ -389,12 +389,12 @@
if (accepted != null) {
try {
accepted.close();
-accepted = null;
} catch(Exception ex) {
msg = sm.getString(endpoint.err.nonfatal,
accepted, ex);
log.warn(msg, ex);
}
+accepted = null;
}
if( ! running ) return null;
wouldn't it be better to put the accepted = null into a finally
block so you clean up even in the (unlikely but possible) case where
close throws an Error (or Throwable) instead of an Exception?
Wouldn't do anything. The 'accepted' variable is local to the stack-frame,
so it goes away if I throw clear of the method. In this case you just get a
DoS condition where no threads are listening on the ServerSocket. I briefly
thought about changing the catch to 'Throwable', but is it really possible
for Socket.close to throw anything other than an Exception?
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21763] - Tomcat 4.1.24 hangs under heavy load using http connector.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21763. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21763 Tomcat 4.1.24 hangs under heavy load using http connector. --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 08:35 --- Created an attachment (id=8182) Binary including the fix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Bill Barker wrote:
On 12 Sep 2003, [EMAIL PROTECTED] wrote:
+++ PoolTcpEndpoint.java 12 Sep 2003 03:51:36 - 1.16
@@ -389,12 +389,12 @@
if (accepted != null) {
try {
accepted.close();
-accepted = null;
} catch(Exception ex) {
msg = sm.getString(endpoint.err.nonfatal,
accepted, ex);
log.warn(msg, ex);
}
+accepted = null;
}
if( ! running ) return null;
wouldn't it be better to put the accepted = null into a finally
block so you clean up even in the (unlikely but possible) case where
close throws an Error (or Throwable) instead of an Exception?
Wouldn't do anything. The 'accepted' variable is local to the stack-frame,
so it goes away if I throw clear of the method. In this case you just get a
DoS condition where no threads are listening on the ServerSocket. I briefly
thought about changing the catch to 'Throwable', but is it really possible
for Socket.close to throw anything other than an Exception?
I don't know. From traces I saw, there are conditions where there could
be no thread listening on the socket (at that point, the connector was
dead, of course), while everything else in the TP was looking ok
(including no deadlock). There didn't seem to be anything in the logs
related to an error during accept.
I'd catch throwable just to be safe, personally :)
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
On Fri, 12 Sep 2003, Bill Barker [EMAIL PROTECTED] wrote: From: Stefan Bodewig [EMAIL PROTECTED] wouldn't it be better to put the accepted = null into a finally block Wouldn't do anything. The 'accepted' variable is local to the stack-frame, so it goes away if I throw clear of the method. OK, thanks. I just looked at the commit mail as I suspect that one of our customer production systems gets bitten by the bug - I didn't look at the complete code. Makes sense, then. I briefly thought about changing the catch to 'Throwable', but is it really possible for Socket.close to throw anything other than an Exception? Everything is possible ;-) I have no idea what the Socket implementation does if shutdown(2) sets errno to ENOTCONN for example (I'd guess, throw a plain SocketException). I don't think that non-Exceptions are too likely to happen and if they do it probably happens in a situation where you can't recover anyway (OutOfMemory, StackOverflow, ThreadDeath ...). Catching Throwable may be the savest thing to do. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23128] New: - ServletRequest.setLocale() sets encoding even when already set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23128.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23128
ServletRequest.setLocale() sets encoding even when already set
Summary: ServletRequest.setLocale() sets encoding even when
already set
Product: Tomcat 4
Version: 4.1.27
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Calling ServletRequest.setLocale(locale) sets charset attribute
even if it was already specified. Following code shows it:
public void doGet (...) {
PrintWriter out;
response.setContentType(text/plain; charset=utf-8);
out = response.getWriter();
out.println( getCharacterEncoding() = + response.getCharacterEncoding() );
response.setLocale(request.getLocale());
out.println( getCharacterEncoding() = + response.getCharacterEncoding() );
}
It will produce output
getCharacterEncoding() = utf-8
getCharacterEncoding() = ISO-8859-2
for my browser with cs locale. This bug was probably introduced
by patch mentioned in bug 6569. To be precise, the Servlet 2.3 javadoc says
for ServletResponse.setLocale():
http://java.sun.com/webservices/docs/1.0/api/javax/servlet/ServletResponse.html#setLocale(java.util.Locale)
Sets the locale of the response, setting the headers (including the
Content-Type's charset) as appropriate.
but the javadoc for Servlet 2.4 is more precise:
http://java.sun.com/webservices/docs/1.2/api/javax/servlet/ServletResponse.html#setLocale(java.util.Locale)
Sets the locale of the response, setting the Content-Language header,
if the response has not been committed yet. It also sets the response's
character encoding appropriately for the locale, if the character
encoding has not been explicitly set using
setContentType(java.lang.String) or
setCharacterEncoding(java.lang.String), getWriter hasn't been called
yet, and the response hasn't been committed yet.
So Servlet 2.3 was vague in this, but Servlet 2.4 says it clearly, that
setLocale() should not change charset, if it is already set.
The last draft of Servlet 2.4 specification say in part 5.4 on page 52,
that explicit specifications take precedence over implicit specifications.
This is a major problem when using JSTL fmt: tags for displaying internationalized
messages, because each fmt: tag calls the setLocale() to set Content-Language
header, and accidentaly changes also the charset. This makes impossible
to display internationalized pages with multilingual content using utf-8,
as the utf-8 charset is always replaced by setLocale() call of the last fmt:
tag.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23128] - ServletRequest.setLocale() sets encoding even when already set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23128.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23128
ServletRequest.setLocale() sets encoding even when already set
--- Additional Comments From [EMAIL PROTECTED] 2003-09-12 09:31 ---
I think that the second implementation mentioned in bug 6569 was the correct
one according to the spec, so you can just return back to it:
public void setLocale(Locale locale) {
[...]
this.locale = locale;
if ((this.encoding == null) (this.context != null)) {
CharsetMapper mapper = context.getCharsetMapper();
this.encoding = mapper.getCharset(locale);
if ((contentType != null) (contentType.indexOf(';') 0)) {
contentType = contentType + ;charset= + encoding;
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23131] New: - catalina crash.. it's still runing in process list but port not binded..
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23131. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23131 catalina crash.. it's still runing in process list but port not binded.. Summary: catalina crash.. it's still runing in process list but port not binded.. Product: Tomcat 5 Version: 5.0.11 Platform: PC URL: http://195.131.71.173 OS/Version: Windows XP Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 12.09.2003 12:54:49 org.apache.catalina.loader.WebappClassLoader modified SEVERE: Resource '/WEB-INF/classes/gpnic/GetTovar.class' is missing 12.09.2003 12:54:49 org.apache.catalina.core.StandardContext reload INFO: Reloading this Context has started 12.09.2003 12:54:54 org.apache.catalina.loader.WebappClassLoader findResourceInternal INFO: Illegal access: this web application instance has been stopped already (the eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact) 12.09.2003 12:54:54 org.apache.catalina.loader.WebappClassLoader findResourceInternal INFO: Illegal access: this web application instance has been stopped already (the eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact) 12.09.2003 12:54:54 org.apache.catalina.loader.WebappClassLoader loadClass INFO: Illegal access: this web application instance has been stopped already (the eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact) 12.09.2003 12:54:54 org.apache.catalina.loader.WebappClassLoader loadClass INFO: Illegal access: this web application instance has been stopped already (the eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact) 12.09.2003 12:54:54 org.apache.catalina.loader.WebappClassLoader loadClass INFO: Illegal access: this web application instance has been stopped already (the eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact) 12.09.2003 12:54:54 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren SEVERE: Exception invoking periodic operation: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: java.lang.IncompatibleClassChangeError: org.apache.commons.logging.impl.SimpleLog at org.apache.commons.logging.impl.LogFactoryImpl.newInstance (LogFactoryImpl.java:532) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance (LogFactoryImpl.java:272) at org.apache.commons.logging.LogFactory.getLog (LogFactory.java:414) at org.apache.catalina.core.StandardContext.start (StandardContext.java:3856) at org.apache.catalina.core.StandardContext.reload (StandardContext.java:2864) at org.apache.catalina.core.StandardContext.backgroundProcess (StandardContext.java:4411) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC hildren(ContainerBase.java:1658) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC hildren(ContainerBase.java:1667) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC hildren(ContainerBase.java:1667) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run (ContainerBase.java:1647) at java.lang.Thread.run(Thread.java:534) Caused by: org.apache.commons.logging.LogConfigurationException: java.lang.IncompatibleClassChangeError: org.apache.commons.logging.impl.SimpleLog at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor (LogFactoryImpl.java:416) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance (LogFactoryImpl.java:525) ... 10 more Caused by: java.lang.IncompatibleClassChangeError: org.apache.commons.logging.impl.SimpleLog at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1252) at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1212) at
DO NOT REPLY [Bug 23131] - catalina crash.. it's still runing in process list but port not binded..
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23131. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23131 catalina crash.. it's still runing in process list but port not binded.. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 10:28 --- Please provide a test case. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 InternalOutputBuffer.java
remm2003/09/12 03:28:38
Modified:http11/src/java/org/apache/coyote/http11 Tag: coyote_10
InternalOutputBuffer.java
Log:
- Port patch: add filering for control chars in the HTTP header.
Revision ChangesPath
No revision
No revision
1.16.2.1 +9 -1
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java
Index: InternalOutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java,v
retrieving revision 1.16
retrieving revision 1.16.2.1
diff -u -r1.16 -r1.16.2.1
--- InternalOutputBuffer.java 22 Nov 2002 15:55:32 - 1.16
+++ InternalOutputBuffer.java 12 Sep 2003 10:28:38 - 1.16.2.1
@@ -490,7 +490,7 @@
*/
public void endHeaders() {
-write(Constants.CRLF);
+write(Constants.CRLF_BYTES);
}
@@ -627,6 +627,14 @@
// High order byte must be zero
//log(Header character is not iso8859_1, +
//not supported yet: + c, Log.ERROR ) ;
+}
+if (c != 9) {
+if ((c = 0) (c = 31)) {
+c = ' ';
+}
+if (c == 127) {
+c = ' ';
+}
}
buf[pos++] = (byte) c;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19245] - pageEncoding in static included file don't affect properly file from which is included
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19245. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19245 pageEncoding in static included file don't affect properly file from which is included --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 10:33 --- Hi I don't want to fight reopens against won't fix ;) but - what about my proposed patch from bug 19617? It makes Tomcat4 MORE specs compliant. Kim-Man Chung said that he has no objections to my patch. Please understand that now it's impossible to use encoding other than iso-8859-1 in included files - it's major flaw for all non-ascii programmers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0.12] Delay
I won't tag 5.0.12 until early next week, because: - we're currently examining and testing fixes for bug 21763; two people have volunteered to test the recent changes, and confirm the problem is fixed - I'm working on adding additional buffering features in Coyote HTTP; the change is not very extensive, so I hope there will not be any regression A 4.1.28 release should also be made soon, incorporating the latest fixes. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf ByteChunk.java
remm2003/09/12 05:58:53
Modified:util/java/org/apache/tomcat/util/buf ByteChunk.java
Log:
- Refactor byte chunk buffering so that the written data fits inside the limit.
The number of byte copies is similar to what it was before.
Revision ChangesPath
1.15 +19 -28
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java
Index: ByteChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- ByteChunk.java2 Sep 2003 21:34:38 - 1.14
+++ ByteChunk.java12 Sep 2003 12:58:53 - 1.15
@@ -338,34 +338,25 @@
// the buffer is already at ( or bigger than ) limit
- // Optimization:
- // If len-avail length ( i.e. after we fill the buffer with
- // what we can, the remaining will fit in the buffer ) we'll just
- // copy the first part, flush, then copy the second part - 1 write
- // and still have some space for more. We'll still have 2 writes, but
- // we write more on the first.
-
- if( len + end 2 * limit ) {
- /* If the request length exceeds the size of the output buffer,
-flush the output buffer and then write the data directly.
-We can't avoid 2 writes, but we can write more on the second
- */
- int avail=limit-end;
- System.arraycopy(src, off, buff, end, avail);
- end += avail;
-
- flushBuffer();
-
- System.arraycopy(src, off+avail, buff, end, len - avail);
- end+= len - avail;
-
- } else {// len buf.length + avail
- // long write - flush the buffer and write the rest
- // directly from source
- flushBuffer();
-
- out.realWriteBytes( src, off, len );
- }
+// We chunk the data into slices fitting in the buffer limit, although
+// if the data is written directly if it doesn't fit
+
+int avail=limit-end;
+System.arraycopy(src, off, buff, end, avail);
+end += avail;
+
+flushBuffer();
+
+int remain = len - avail;
+
+while (remain (limit - end)) {
+out.realWriteBytes( src, (off + len) - remain, limit - end );
+remain = remain - (limit - end);
+}
+
+System.arraycopy(src, (off + len) - remain, buff, end, remain);
+end += remain;
+
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Constants.java Http11Processor.java Http11Protocol.java InternalOutputBuffer.java
remm2003/09/12 06:15:36
Modified:http11/src/java/org/apache/coyote/http11 Constants.java
Http11Processor.java Http11Protocol.java
InternalOutputBuffer.java
Log:
- Add a buffer at the socket layer, configured using the socketBuffer
attribute. Add handling for explicit client flushes.
Revision ChangesPath
1.17 +1 -1
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Constants.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- Constants.java2 Sep 2003 21:34:39 - 1.16
+++ Constants.java12 Sep 2003 13:15:36 - 1.17
@@ -239,7 +239,7 @@
/**
* Ack string when pipelining HTTP requests.
*/
-public static final byte[] ACK =
+public static final byte[] ACK_BYTES =
HTTP/1.1 100 Continue\r\n\r\n.getBytes();
1.78 +30 -0
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -r1.77 -r1.78
--- Http11Processor.java 7 Sep 2003 18:04:58 - 1.77
+++ Http11Processor.java 12 Sep 2003 13:15:36 - 1.78
@@ -274,6 +274,12 @@
/**
+ * Socket buffering.
+ */
+protected int socketBuffer = -1;
+
+
+/**
* List of user agents to not use gzip with
*/
protected String[] noCompressionUserAgents = null;
@@ -534,6 +540,21 @@
}
/**
+ * Set the socket buffer flag.
+ */
+public void setSocketBuffer(int socketBuffer) {
+this.socketBuffer = socketBuffer;
+outputBuffer.setSocketBuffer(socketBuffer);
+}
+
+/**
+ * Get the socket buffer flag.
+ */
+public int getSocketBuffer() {
+return socketBuffer;
+}
+
+/**
* Set the upload timeout.
*/
public void setTimeout( int timeouts ) {
@@ -767,6 +788,15 @@
// Set error flag
error = true;
}
+}
+
+} else if (actionCode == ActionCode.ACTION_CLIENT_FLUSH) {
+
+try {
+outputBuffer.flush();
+} catch (IOException e) {
+// Set error flag
+error = true;
}
} else if (actionCode == ActionCode.ACTION_CLOSE) {
1.36 +6 -0
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
Index: Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- Http11Protocol.java 2 Sep 2003 21:34:39 - 1.35
+++ Http11Protocol.java 12 Sep 2003 13:15:36 - 1.36
@@ -246,6 +246,7 @@
private String reportedname;
private int socketCloseDelay=-1;
private boolean disableUploadTimeout = true;
+private int socketBuffer = 1500;
private Adapter adapter;
private Http11ConnectionHandler cHandler;
@@ -318,6 +319,10 @@
disableUploadTimeout = isDisabled;
}
+public void setSocketBuffer(int valueI) {
+socketBuffer = valueI;
+}
+
public void setCompression(String valueS) {
compression = valueS;
}
@@ -463,6 +468,7 @@
processor.setTimeout( proto.timeout );
processor.setDisableUploadTimeout( proto.disableUploadTimeout );
processor.setCompression( proto.compression );
+processor.setSocketBuffer( proto.socketBuffer );
thData[Http11Protocol.THREAD_DATA_PROCESSOR]=processor;
1.19 +87 -6
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java
Index: InternalOutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- InternalOutputBuffer.java 11 Sep 2003 07:03:58 - 1.18
+++ InternalOutputBuffer.java 12 Sep 2003 13:15:36 - 1.19
@@ -77,7 +77,8 @@
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 OutputBuffer.java
remm2003/09/12 06:16:41
Modified:catalina/src/share/org/apache/coyote/tomcat5
OutputBuffer.java
Log:
- When flush is called, call the appropriate action to do a lower level flush.
- Don't flush at the end of request processing.
Revision ChangesPath
1.6 +18 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/OutputBuffer.java
Index: OutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/OutputBuffer.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- OutputBuffer.java 2 Sep 2003 21:21:59 - 1.5
+++ OutputBuffer.java 12 Sep 2003 13:16:41 - 1.6
@@ -68,6 +68,7 @@
import java.util.HashMap;
import org.apache.catalina.connector.ClientAbortException;
+import org.apache.coyote.ActionCode;
import org.apache.coyote.Response;
import org.apache.tomcat.util.buf.ByteChunk;
import org.apache.tomcat.util.buf.C2BConverter;
@@ -321,7 +322,7 @@
}
}
-flush();
+doFlush(false);
closed = true;
coyoteResponse.finish();
@@ -336,6 +337,17 @@
*/
public void flush()
throws IOException {
+doFlush(true);
+}
+
+
+/**
+ * Flush bytes or chars contained in the buffer.
+ *
+ * @throws IOException An underlying IOException occurred
+ */
+protected void doFlush(boolean realFlush)
+throws IOException {
if (suspended)
return;
@@ -352,6 +364,11 @@
coyoteResponse.sendHeaders();
}
doFlush = false;
+
+if (realFlush) {
+coyoteResponse.action(ActionCode.ACTION_CLIENT_FLUSH,
+ coyoteResponse);
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java
remm2003/09/12 06:17:06 Modified:catalina/src/share/org/apache/catalina/valves ErrorReportValve.java Log: - Remove useless flush. Revision ChangesPath 1.11 +4 -5 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java Index: ErrorReportValve.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- ErrorReportValve.java 2 Sep 2003 21:22:03 - 1.10 +++ ErrorReportValve.java 12 Sep 2003 13:17:06 - 1.11 @@ -370,7 +370,6 @@ // If writer is null, it's an indication that the response has // been hard committed already, which should never happen writer.write(sb.toString()); -writer.flush(); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Need Tomcat 4.0.6 LE (jdk1.4) Binaries]
Getting a lot of those... You might want to update the links in the website to point to the mirrors? Pier ---BeginMessage--- We are using Tomcat 4.0.6 and I need to download binaries, both the Windows install version and for Linux. Recently 4.0.6 downloads have disappeared from your website. The page http://jakarta.apache.org/site/other-releases.html has a link for 4.0.6 binaries, but I get a 403 Forbidden error when I follow the link (http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.6/). Can you help me? --Marc Riehm, Maptuit Corporation.---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23105] - JkMount overrides Alias
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23105. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23105 JkMount overrides Alias --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 13:32 --- The mod_jk I tested it with is mod_jk-1.2.3 is this problem addressed in the 1.2.5 version? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23105] - JkMount overrides Alias
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23105. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23105 JkMount overrides Alias --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 13:35 --- Works has been conducted in jk 1.2.4 around DirectoryIndex which should help you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
remm2003/09/12 07:06:21
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
- ThreadDeath is a more appropriate error in this situation.
Revision ChangesPath
1.26 +2 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- WebappClassLoader.java6 Sep 2003 17:49:31 - 1.25
+++ WebappClassLoader.java12 Sep 2003 14:06:21 - 1.26
@@ -1249,7 +1249,7 @@
// Don't load classes if class loader is stopped
if (!started) {
log.info(sm.getString(webappClassLoader.stopped));
-throw new IncompatibleClassChangeError(name);
+throw new ThreadDeath();
}
// (0) Check our previously loaded local class cache
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java
remm2003/09/12 07:07:30
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
- Oops, the context classloader binding is wrong, which does not allow a
reload (bug 23131).
Revision ChangesPath
1.91 +11 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.90
retrieving revision 1.91
diff -u -r1.90 -r1.91
--- StandardContext.java 9 Sep 2003 15:27:00 - 1.90
+++ StandardContext.java 12 Sep 2003 14:07:30 - 1.91
@@ -4380,7 +4380,16 @@
if (getLoader() != null) {
if (reloadable (getLoader().modified())) {
-reload();
+try {
+Thread.currentThread().setContextClassLoader
+(StandardContext.class.getClassLoader());
+reload();
+} finally {
+if (getLoader() != null) {
+Thread.currentThread().setContextClassLoader
+(getLoader().getClassLoader());
+}
+}
}
if (getLoader() instanceof WebappLoader) {
((WebappLoader) getLoader()).closeJARs(false);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk2 on aix - Urgent
Greetings, I was installing mod_jk2 to interact between apache 2 and tomcat 1.4. I was not able to build the module. It says jni_md.h is missing. I am having java1.3.1 and I do not have include directory with it. Can somebody will help mw with it. Can anybody has compiled mod_jk2 for aix 5.1 or can any body provide me the include directory. Ajay _ Attention NRIs! Banking worries? http://server1.msn.co.in/msnspecials/nriservices/index.asp Get smart tips. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationDispatcher.java
remm2003/09/12 10:04:12
Modified:catalina/src/share/org/apache/catalina/core
ApplicationDispatcher.java
Log:
- Remove overriding the mapped servlet path with the jsp-file. I cannot find
anything in the specification which says that it must be done, and it contradicts
all the other mapping rules. This code was introduced in Tomcat 4.0 b5 (yes,
I had to go back for a *while*).
- This fixes tester failures with the latest changes to JSP servlet.
Revision ChangesPath
1.26 +4 -13
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
Index: ApplicationDispatcher.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- ApplicationDispatcher.java2 Sep 2003 21:22:04 - 1.25
+++ ApplicationDispatcher.java12 Sep 2003 17:04:12 - 1.26
@@ -196,15 +196,6 @@
this.pathInfo + , queryString= + queryString +
, name= + this.name);
-// If this is a wrapper for a JSP page (jsp-file), tweak
-// the request parameters appropriately
-String jspFile = wrapper.getJspFile();
-if (jspFile != null) {
-if ( log.isDebugEnabled() )
-log.debug(--servletPath= + jspFile);
-this.servletPath = jspFile;
-}
-
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
BindException :: Shutdown Port 8005 :: Solaris 5.9
Hi all, I am experiencing difficulties with port 8005. It crashes with a BindException after trying to start it. OS: SunOS 5.9 www2# java -showversion java version 1.4.0_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_03-b04) Java HotSpot(TM) Client VM (build 1.4.0_03-b04, mixed mode) I have tried 5 different Tomcat Versions: 3.3.1a - Works 4.1.18 - Crashes 4.1.27 - Crashes 5.0.11 - Crashes Sun JWSDP 1.2 - Crashes In all cases after waiting for $CATALINA_HOME/bin/startup.sh quite a while. I get the following error at $CATALINA_HOME/logs/catalina.out: StandardServer.await: create[8005]: java.net.BindException: Cannot assign requested address java.net.BindException: Cannot assign requested address at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:321) at java.net.ServerSocket.bind(ServerSocket.java:308) at java.net.ServerSocket.bind(ServerSocket.java:266) at java.net.ServerSocket.init(ServerSocket.java:182) at org.apache.catalina.core.StandardServer.await(StandardServer.java:523) at org.apache.catalina.startup.Catalina.await(Catalina.java:633) at org.apache.catalina.startup.Catalina.start(Catalina.java:595) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces I have checked if I have a server using that specific port and it doesn´t seem to be the case. www2# netstat -an | grep 8080 www2# I even tried by changing the port on the server.xml file to another and it continues to crash. The user with which I am trying to start the service is root. I don´t see why it wouldn´t have permission to start it. I have checked who is the owner of the Tomcat Files, and in all cases it is root. www2# ls -la -rwxr-xr-x 1 root root 788 Dec 19 2002 startup.sh Do you have a clue on what is going on here, is there any well known problem or - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: BindException :: Shutdown Port 8005 :: Solaris 5.9
Hey, I'm new to the Tomcat experience. I don't know it this helps, but have you tried to create a virtual ip and start Tomcat that way? I ran into the same problem, so I ran it on its own IP and it works fine now. -Original Message- From: Juanpablo Lajud [mailto:[EMAIL PROTECTED] Sent: Friday, September 12, 2003 3:20 PM To: [EMAIL PROTECTED] Subject: BindException :: Shutdown Port 8005 :: Solaris 5.9 Hi all, I am experiencing difficulties with port 8005. It crashes with a BindException after trying to start it. OS: SunOS 5.9 www2# java -showversion java version 1.4.0_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_03-b04) Java HotSpot(TM) Client VM (build 1.4.0_03-b04, mixed mode) I have tried 5 different Tomcat Versions: 3.3.1a - Works 4.1.18 - Crashes 4.1.27 - Crashes 5.0.11 - Crashes Sun JWSDP 1.2 - Crashes In all cases after waiting for $CATALINA_HOME/bin/startup.sh quite a while. I get the following error at $CATALINA_HOME/logs/catalina.out: StandardServer.await: create[8005]: java.net.BindException: Cannot assign requested address java.net.BindException: Cannot assign requested address at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:321) at java.net.ServerSocket.bind(ServerSocket.java:308) at java.net.ServerSocket.bind(ServerSocket.java:266) at java.net.ServerSocket.init(ServerSocket.java:182) at org.apache.catalina.core.StandardServer.await(StandardServer.java:523) at org.apache.catalina.startup.Catalina.await(Catalina.java:633) at org.apache.catalina.startup.Catalina.start(Catalina.java:595) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces I have checked if I have a server using that specific port and it doesn´t seem to be the case. www2# netstat -an | grep 8080 www2# I even tried by changing the port on the server.xml file to another and it continues to crash. The user with which I am trying to start the service is root. I don´t see why it wouldn´t have permission to start it. I have checked who is the owner of the Tomcat Files, and in all cases it is root. www2# ls -la -rwxr-xr-x 1 root root 788 Dec 19 2002 startup.sh Do you have a clue on what is going on here, is there any well known problem or - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23146] New: - Calling socket.setTcpNoDelay causes connector to disconnect
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23146. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23146 Calling socket.setTcpNoDelay causes connector to disconnect Summary: Calling socket.setTcpNoDelay causes connector to disconnect Product: Tomcat 4 Version: 4.1.27 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Connector:HTTP/1.1 (deprecated) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In org.apache.catalina.connector.HttpConnector, line 1028, the connector calls setTcpNoDelay on the newly created socket. This method can throw a SocketException, which is not caught. The exception causes the HttpConnector thread to finish, removing the Socket object without explicitly closing the underlying network socket. Tomcat then attempts to recreate the HttpConnector, which attempts to open a new socket with the same address binding. This will fail, and the application will then cease to respond on the given HTTP port. This is happening very intermittently on a production machine we have. This is very difficult to replicate, but I hope that we have given enough details to fix the underlying problem, which is the uncaught SocketException. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23146] - Calling socket.setTcpNoDelay causes connector to disconnect
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23146. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23146 Calling socket.setTcpNoDelay causes connector to disconnect --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 19:38 --- We are getting this on a Solaris box. Occasionally occurs. I have filed a bug with Sun, because I can't see why this should be failing. I searched the web and found two previous cases of this, one Jetty and one Tomcat, but no solution was found for either. Both on solaris boxes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23146] - Calling socket.setTcpNoDelay causes connector to disconnect
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23146. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23146 Calling socket.setTcpNoDelay causes connector to disconnect --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 19:40 --- I think that's good, but it doesn't really change the fact that the exception isn't being checked for at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23146] - Calling socket.setTcpNoDelay causes connector to disconnect
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23146. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23146 Calling socket.setTcpNoDelay causes connector to disconnect --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 19:49 --- You should move to using the CoyoteConnector. Its a lot better in general. Luckily, it calls setTcpNoDelay in the WorkerThread, rather than in the ServerSocket thread. So your problem doesn't occur. Although as far as I can tell there is less, although likely still some threads serving the request. java.net.SocketException: Invalid argument at java.net.PlainSocketImpl.socketSetOption(Native Method) at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:240) at java.net.Socket.setTcpNoDelay(Socket.java:745) at org.apache.tomcat.util.net.PoolTcpEndpoint.setSocketOptions(PoolTcpEndpoint.java:468) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:564) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619) at java.lang.Thread.run(Thread.java:536) From some of the open bugs, I think the Catalina HttpConnector is basically unmaintained. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util RequestUtil.java
luehe 2003/09/12 12:54:57
Modified:catalina/src/share/org/apache/catalina/util RequestUtil.java
Log:
Reverted patch for 4918152 (using % in the value of jsp:param
corrupts the query string), as it is not needed for JSP 2.0.
JSP.5.6 (jsp:param) has clarified the potential trouble spot as follows:
The parameter names and values specified should be left unencoded by the
page author. The JSP container must encode the parameter names and values
using the character encoding from the request object when necessary. For
example, if the container chooses to append the parameters to the URL in
the dispatched request, both the names and values must be encoded as per
the content type application/x-www-form-urlencoded in the HTML specification.
Revision ChangesPath
1.6 +6 -11
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/RequestUtil.java
Index: RequestUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- RequestUtil.java 11 Sep 2003 01:59:51 - 1.5
+++ RequestUtil.java 12 Sep 2003 19:54:56 - 1.6
@@ -536,13 +536,8 @@
data[ox++] = (byte)' ';
break;
case '%':
-if ((ix = (data.length - 2))
-((char)data[ix] != '') ((char)data[ix+1] != '')) {
-data[ox++] = (byte)((convertHexDigit(data[ix++]) 4)
- + convertHexDigit(data[ix++]));
-} else {
-data[ox++] = c;
-}
+data[ox++] = (byte)((convertHexDigit(data[ix++]) 4)
++ convertHexDigit(data[ix++]));
break;
default:
data[ox++] = c;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Performance Problems in Coyote Chunking
Steve Appling wrote: The following patch combines the 3 packets that were generated for each chunk into just one packet. There are more optimizations elsewhere - I'll keep looking. Patch of org.apache.coyote.http11.filters.ChunkedOutputFilter from 4.1.27 src. After testing and benching, implementing buffering at the lower layer is much better, as it avoids introducing complexity in all the levels of processing, and is more powerful. The performance impact of the new behavior is minimal (using a worst case scenario of a static file, the difference is about 2-3%). I believe the updated implementation will meet your needs. What's the most optimal packet size overall, BTW ? 1500 ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Performance Problems in Coyote Chunking
On Fri, 12 Sep 2003, Remy Maucherat wrote: Steve Appling wrote: The following patch combines the 3 packets that were generated for each chunk into just one packet. There are more optimizations elsewhere - I'll keep looking. Patch of org.apache.coyote.http11.filters.ChunkedOutputFilter from 4.1.27 src. After testing and benching, implementing buffering at the lower layer is much better, as it avoids introducing complexity in all the levels of processing, and is more powerful. The performance impact of the new behavior is minimal (using a worst case scenario of a static file, the difference is about 2-3%). I believe the updated implementation will meet your needs. What's the most optimal packet size overall, BTW ? 1500 ? there is nothing inherently relating chunk sizes in chunked output to packet sizes. From the network perspective, you want some reasonably sized (at a minimum 8k; that is what Apache uses) buffer between the code generating content and the network, and you never want to explicitly flush that to the network unless you are actually at the end of a response. You have no idea what the MTU on the network is, and your code shouldn't care. It should just present the data to the network stack in as big of a buffer as practical (ie. in one write call), and let it worry about that. You don't want to be creating HTTP chunks arbitrarily, you only want to do that when you are writing a buffer to the network layer. Normally one HTTP chunk should span multiple packets when the network layer puts it on the wire. In an ideal world, you could just use a GatheringByteChannel to present the chunk header and the chunk to the network layer at the same time (ie. ala writev()), but compatibility issues are a problem for now. In addition, when serving truly static content where you can determine the content length in advance (eg. serving an image from disk), avoiding chunking alltogether and just setting a content length is definitely preferred. At the end, if you are sending a response with 300 bytes of headers and 800 bytes of content, the content should be in at most one chunk and the headers and content should end up on the network in the same packet, assuming a MTU of at least 1500. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
billbarker2003/09/12 20:59:57
Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Log:
Catch all throwables when trying to close the socket.
Revision ChangesPath
1.17 +4 -4
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
Index: PoolTcpEndpoint.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- PoolTcpEndpoint.java 12 Sep 2003 03:51:36 - 1.16
+++ PoolTcpEndpoint.java 13 Sep 2003 03:59:57 - 1.17
@@ -389,7 +389,7 @@
if (accepted != null) {
try {
accepted.close();
-} catch(Exception ex) {
+} catch(Throwable ex) {
msg = sm.getString(endpoint.err.nonfatal,
accepted, ex);
log.warn(msg, ex);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
billbarker2003/09/12 21:01:24
Modified:util/java/org/apache/tomcat/util/net Tag: coyote_10
PoolTcpEndpoint.java
Log:
Port patch.
Revision ChangesPath
No revision
No revision
1.12.2.2 +4 -4
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
Index: PoolTcpEndpoint.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
retrieving revision 1.12.2.1
retrieving revision 1.12.2.2
diff -u -r1.12.2.1 -r1.12.2.2
--- PoolTcpEndpoint.java 12 Sep 2003 03:53:03 - 1.12.2.1
+++ PoolTcpEndpoint.java 13 Sep 2003 04:01:24 - 1.12.2.2
@@ -380,7 +380,7 @@
if (accepted != null) {
try {
accepted.close();
-} catch(Exception ex) {
+} catch(Throwable ex) {
msg = sm.getString(endpoint.err.nonfatal,
accepted, ex);
log.warn(msg, ex);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
