AJP13 problem on Tomcat 4.1.15
While playing with 4.1.15, I discovered some nasty problem with the AJP13 implementation from JTC. 1) TC 4.1.15 set socket timeout (2 = 20s) which make give you Read exception after 20s of inactivity between webserver and Tomcat : 90577 [Thread-6] ERROR common.ChannelSocket - Error, closing connection java.io.InterruptedIOException: Read timed out at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:113) at java.io.BufferedInputStream.fill(BufferedInputStream.java:202) at java.io.BufferedInputStream.read1(BufferedInputStream.java:241) at java.io.BufferedInputStream.read(BufferedInputStream.java:296) at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:487) at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:425) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:540) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:654) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:533) at java.lang.Thread.run(Thread.java:512) The problem is that the socket is NOT close at that time and even if TC free the thread, the socket still exists and make webserver think that it could send request (and sus wait forever replies ) I'll commit a patch to make the socket close in a finally area. 2) The second problem is related to the socket timeout settings. In Ajp13 protocol, the webserver decide when it had to close the socket since it's the client (initiator) of the connection. if tomcat close the socket, the webserver won't detect before it will try to read replies. It's a known problem with Sockets implementation which make that write() calls on a half-closed connection DIDN'T return error CODE, only read() calls with report the error that the remote decided to close the connection. As such I strongly recommand to disable the connectionTime by removing the connectionTimeout in server.xml : !-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 -- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=0 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ You should know that mod_jk 1.2.0 (don't know for latest 2.0.x), have settings now which make webserver close unused sockets after some time, just to be sure that the tomcat didn't have TOO many unused threads. 3) I saw that linger are set to 100, which is not recommanded in Regards. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Probem: HTTP Status 405 - HTTP method GET is not supported by this URL
http://localhost:8080/mht/servlet/HttpReceive is the url... HTTP Status 405 - HTTP method GET is not supported by this URL type Status report message HTTP method GET is not supported by this URL description The specified HTTP method is not allowed for the requested resource (HTTP method GET is not supported by this URL). How can I fix these problem ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14699] New: - Scripting variables declared AT_END do not work when tag implements TryCatchFinally.
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=14699.
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=14699
Scripting variables declared AT_END do not work when tag implements TryCatchFinally.
Summary: Scripting variables declared AT_END do not work when tag
implements TryCatchFinally.
Product: Tomcat 4
Version: 4.1.12
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Critical
Priority: Other
Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Scripting variables declared within tag implementing TryCatchFinally interface
are positioned inside try block in the generated code thus hiding their
visibility to rest of the page.
Example (foo.tld not included):
test.jsp:
%@taglib uri=foo prefix=foo %
foo:foo
/foo:foo
%= test %
FooTag.java:
package foo;
import javax.servlet.jsp.tagext.*;
public class FooTag extends BodyTagSupport implements TryCatchFinally {
public int doEndTag() {
pageContext.setAttribute(test, testValue);
return EVAL_PAGE;
}
public void doCatch(Throwable exc) {
}
public void doFinally() {
}
}
FooTEI.java:
package foo;
import javax.servlet.jsp.tagext.*;
public class FooTEI extends TagExtraInfo {
private static final String DEFAULT_VAR_NAME = test;
public VariableInfo[] getVariableInfo(TagData tagData) {
String varName = null;
VariableInfo varInfo = new VariableInfo(
(varName==null?DEFAULT_VAR_NAME:varName),
java.lang.String, true,
VariableInfo.AT_END);
return new VariableInfo[] {varInfo};
}
}
Resulting compile exception:
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: 5 in the jsp file: /test.jsp
Generated servlet error:
[javac] Compiling 1 source file
C:\Server\Tomcat4.1\work\Standalone\localhost\_\test_jsp.java:86: cannot resolve
symbol
symbol : variable test
location: class org.apache.jsp.test_jsp
out.print( test );
^
1 error
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JK2] Apache2 add read-ahead for POST data
Mladen Turk wrote: Hi, Seems that we have some problems reading POST data from Apache2. My proposal is to add the read ahead buffer. Looking at some modules I found that most of them has that feature. For example mod_isapi has a default read ahead buffer length of 49152 bytes (48 k). (Why?) Question: Can we make some good example that will allow POST data over 16K (4 buckets)? MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] I have used the attached testservlet to test big POST on Linux and Solaris and I have not detected a problem. (Well I have stopped testing at about 20 k). Cheers Jean-frederic -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Nightly TC 3.3.x builds not working anymore?
Hi, the nightly build of Tomcat 3.3.x seems to have stopped at 08-Nov-2002. Any Idea, why? Cheers, Hans -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Nightly TC 3.3.x builds not working anymore?
Hans Schmid wrote: Hi, the nightly build of Tomcat 3.3.x seems to have stopped at 08-Nov-2002. Any Idea, why? Cheers, Hans -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] What's the error ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Changing port number of tomcat
How can i change the default port number which is 8080 to any number ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14282] - mod_jk/ajp13 returns wrong response after bad chunk-encoding request
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=14282. 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=14282 mod_jk/ajp13 returns wrong response after bad chunk-encoding request [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 10:03 --- I didn't see such behaviour, Apache 1.3 return me error 400, Bad request. I mark this to WORKSFORME until someone provide a reproductable test pattern -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Changing port number of tomcat
Just take a look in the server.xml configuration file. In this file you find a xml document that represents the configuration for Tomcat $TOMCAT_HOME/conf/server.xml). Here : !-- Define a non-SSL HTTP/1.1 Connector on port 8080 -- Connector className=org.apache.catalina.connector.http.HttpConnector port=80 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=6 / - Original Message - From: myAyala TAN, Nelson C. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 20, 2002 6:35 AM Subject: Changing port number of tomcat How can i change the default port number which is 8080 to any number ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Probem: HTTP Status 405 - HTTP method GET is not supported by this URL
Check out if the servlet supports GET requests. Pedro Igor - Original Message - From: myAyala TAN, Nelson C. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 20, 2002 5:28 AM Subject: Probem: HTTP Status 405 - HTTP method GET is not supported by this URL http://localhost:8080/mht/servlet/HttpReceive is the url... HTTP Status 405 - HTTP method GET is not supported by this URL type Status report message HTTP method GET is not supported by this URL description The specified HTTP method is not allowed for the requested resource (HTTP method GET is not supported by this URL). How can I fix these problem ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: Nightly TC 3.3.x builds not working anymore?
Last time they were created was 08-Nov-2002 but today is the 20.11.2002 ;) http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3.x/ Parent Directory - JmxSupport.war 08-Nov-2002 06:28 459K PasswordPrompter.war08-Nov-2002 06:28 23K StreamHandler.war 08-Nov-2002 06:28 9.4K jakarta-tomcat-3.3.2-dev-src.tar.gz 08-Nov-2002 06:07 2.9M GZIP compressed file jakarta-tomcat-3.3.2-dev-src.zip08-Nov-2002 05:22 3.1M jakarta-tomcat-3.3.2-dev.tar.gz 08-Nov-2002 06:08 5.4M GZIP compressed file jakarta-tomcat-3.3.2-dev.zip08-Nov-2002 05:27 5.5M jsp-tests.war 08-Nov-2002 06:28 318K servlet-tests.war 08-Nov-2002 06:28 1.8M test.war08-Nov-2002 06:28 165K -Ursprungliche Nachricht- Von: Henri Gomez [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 20. November 2002 10:41 An: Tomcat Developers List Betreff: Re: Nightly TC 3.3.x builds not working anymore? Hans Schmid wrote: Hi, the nightly build of Tomcat 3.3.x seems to have stopped at 08-Nov-2002. Any Idea, why? Cheers, Hans -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] What's the error ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[JK2] jni channel doesn't send POST data (WAS: [JK2] Apache2 add read-ahead for POST data)
Hi, Apache isn't the bugger here. The jni itself is unable to process the POST data. The channel_jni is invoked for the getChunk (id 6), but then nothing happens (at least I wasn't been able to trace any jni_send). It invokes the response dispatcher, but then nothing happens. (Think that this message should be written back as requested) like for stream channels in the processCallbacks. Now I can check for JK_HANDLER_RESPONSE after calling dispatch and write the post data, but that doesn't help. The message is formatted correctly, but seems like Java part disregards that. Am I missing something here? Costin? MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Nightly TC 3.3.x builds not working anymore?
Hi Hans, The 3.3.x nightly is currently run by hand so that the zips are built on Windows and the tar.gzs are build under Unix. I typically update it after I see changes come through. I'll run another build to get things more current, in case I have missed something. I hope to start helping more soon on the various Tomcats, but to this point a recent task assignment in my day job has kept me very busy. Cheers, Larry -Original Message- From: Hans Schmid [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 5:51 AM To: Tomcat Developers List Subject: AW: Nightly TC 3.3.x builds not working anymore? Last time they were created was 08-Nov-2002 but today is the 20.11.2002 ;) http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3.x/ Parent Directory - JmxSupport.war 08-Nov-2002 06:28 459K PasswordPrompter.war08-Nov-2002 06:28 23K StreamHandler.war 08-Nov-2002 06:28 9.4K jakarta-tomcat-3.3.2-dev-src.tar.gz 08-Nov-2002 06:07 2.9M GZIP compressed file jakarta-tomcat-3.3.2-dev-src.zip08-Nov-2002 05:22 3.1M jakarta-tomcat-3.3.2-dev.tar.gz 08-Nov-2002 06:08 5.4M GZIP compressed file jakarta-tomcat-3.3.2-dev.zip08-Nov-2002 05:27 5.5M jsp-tests.war 08-Nov-2002 06:28 318K servlet-tests.war 08-Nov-2002 06:28 1.8M test.war08-Nov-2002 06:28 165K -Ursprungliche Nachricht- Von: Henri Gomez [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 20. November 2002 10:41 An: Tomcat Developers List Betreff: Re: Nightly TC 3.3.x builds not working anymore? Hans Schmid wrote: Hi, the nightly build of Tomcat 3.3.x seems to have stopped at 08-Nov-2002. Any Idea, why? Cheers, Hans -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] What's the error ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteWriter.java
remm2002/11/20 05:47:48
Modified:coyote/src/java/org/apache/coyote/tomcat5 CoyoteWriter.java
Log:
- Full reimplementation of PrintWriter (more optimized for web oriented
applications).
- Fix bug 14658.
Revision ChangesPath
1.2 +181 -15
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteWriter.java
Index: CoyoteWriter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteWriter.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CoyoteWriter.java 4 Aug 2002 19:39:49 - 1.1
+++ CoyoteWriter.java 20 Nov 2002 13:47:48 - 1.2
@@ -68,17 +68,23 @@
/**
* Coyote implementation of the servlet writer.
*
- * @author Costin Manolache
* @author Remy Maucherat
*/
final class CoyoteWriter
extends PrintWriter {
+// -- Constants
+
+
+private static final char[] LINE_SEP = { '\r', '\n' };
+
+
// - Instance Variables
protected OutputBuffer ob;
+protected boolean error = false;
// --- Constructors
@@ -94,43 +100,203 @@
public void flush() {
-super.flush();
-}
-
-public void write(char buf[], int offset, int count) {
-super.write(buf, offset, count);
-}
+if (error)
+return;
+try {
+ob.flush();
+} catch (IOException e) {
+error = true;
+}
-public void write(String str) {
-super.write( str );
}
public void close() {
+
// We don't close the PrintWriter - super() is not called,
// so the stream can be reused. We close ob.
try {
ob.close();
} catch (IOException ex ) {
-ex.printStackTrace();
+;
}
+error = false;
+
+}
+
+
+public boolean checkError() {
+flush();
+return error;
+}
+
+
+public void write(int c) {
+
+if (error)
+return;
+
+try {
+ob.write(c);
+} catch (IOException e) {
+error = true;
+}
+
+}
+
+
+public void write(char buf[], int off, int len) {
+
+if (error)
+return;
+
+try {
+ob.write(buf, off, len);
+} catch (IOException e) {
+error = true;
+}
+
+}
+
+
+public void write(char buf[]) {
+ write(buf, 0, buf.length);
+}
+
+
+public void write(String s, int off, int len) {
+
+if (error)
+return;
+
+try {
+ob.write(s, off, len);
+} catch (IOException e) {
+error = true;
+}
+
+}
+
+
+public void write(String s) {
+write(s, 0, s.length());
}
// PrintWriter Methods
-public void print(String str) {
-super.print( str );
+public void print(boolean b) {
+if (b) {
+write(true);
+} else {
+write(false);
+}
}
-public void println(String str) {
-super.println(str);
+public void print(char c) {
+write(c);
}
-}
+public void print(int i) {
+write(String.valueOf(i));
+}
+
+
+public void print(long l) {
+write(String.valueOf(l));
+}
+
+
+public void print(float f) {
+write(String.valueOf(f));
+}
+
+
+public void print(double d) {
+write(String.valueOf(d));
+}
+
+public void print(char s[]) {
+write(s);
+}
+
+
+public void print(String s) {
+if (s == null) {
+s = null;
+}
+write(s);
+}
+
+
+public void print(Object obj) {
+write(String.valueOf(obj));
+}
+
+
+public void println() {
+write(LINE_SEP);
+}
+
+
+public void println(boolean b) {
+print(b);
+println();
+}
+
+
+public void println(char c) {
+print(c);
+println();
+}
+
+
+public void println(int i) {
+print(i);
+println();
+}
+
+
+public void println(long l) {
+print(l);
+println();
+}
+
+
+public void println(float f) {
+print(f);
+println();
+}
+
+
+
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteWriter.java
remm2002/11/20 05:47:58
Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteWriter.java
Log:
- Full reimplementation of PrintWriter (more optimized for web oriented
applications).
- Fix bug 14658.
Revision ChangesPath
1.2 +181 -15
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteWriter.java
Index: CoyoteWriter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteWriter.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CoyoteWriter.java 7 Mar 2002 04:27:23 - 1.1
+++ CoyoteWriter.java 20 Nov 2002 13:47:58 - 1.2
@@ -68,17 +68,23 @@
/**
* Coyote implementation of the servlet writer.
*
- * @author Costin Manolache
* @author Remy Maucherat
*/
final class CoyoteWriter
extends PrintWriter {
+// -- Constants
+
+
+private static final char[] LINE_SEP = { '\r', '\n' };
+
+
// - Instance Variables
protected OutputBuffer ob;
+protected boolean error = false;
// --- Constructors
@@ -94,43 +100,203 @@
public void flush() {
-super.flush();
-}
-
-public void write(char buf[], int offset, int count) {
-super.write(buf, offset, count);
-}
+if (error)
+return;
+try {
+ob.flush();
+} catch (IOException e) {
+error = true;
+}
-public void write(String str) {
-super.write( str );
}
public void close() {
+
// We don't close the PrintWriter - super() is not called,
// so the stream can be reused. We close ob.
try {
ob.close();
} catch (IOException ex ) {
-ex.printStackTrace();
+;
}
+error = false;
+
+}
+
+
+public boolean checkError() {
+flush();
+return error;
+}
+
+
+public void write(int c) {
+
+if (error)
+return;
+
+try {
+ob.write(c);
+} catch (IOException e) {
+error = true;
+}
+
+}
+
+
+public void write(char buf[], int off, int len) {
+
+if (error)
+return;
+
+try {
+ob.write(buf, off, len);
+} catch (IOException e) {
+error = true;
+}
+
+}
+
+
+public void write(char buf[]) {
+ write(buf, 0, buf.length);
+}
+
+
+public void write(String s, int off, int len) {
+
+if (error)
+return;
+
+try {
+ob.write(s, off, len);
+} catch (IOException e) {
+error = true;
+}
+
+}
+
+
+public void write(String s) {
+write(s, 0, s.length());
}
// PrintWriter Methods
-public void print(String str) {
-super.print( str );
+public void print(boolean b) {
+if (b) {
+write(true);
+} else {
+write(false);
+}
}
-public void println(String str) {
-super.println(str);
+public void print(char c) {
+write(c);
}
-}
+public void print(int i) {
+write(String.valueOf(i));
+}
+
+
+public void print(long l) {
+write(String.valueOf(l));
+}
+
+
+public void print(float f) {
+write(String.valueOf(f));
+}
+
+
+public void print(double d) {
+write(String.valueOf(d));
+}
+
+public void print(char s[]) {
+write(s);
+}
+
+
+public void print(String s) {
+if (s == null) {
+s = null;
+}
+write(s);
+}
+
+
+public void print(Object obj) {
+write(String.valueOf(obj));
+}
+
+
+public void println() {
+write(LINE_SEP);
+}
+
+
+public void println(boolean b) {
+print(b);
+println();
+}
+
+
+public void println(char c) {
+print(c);
+println();
+}
+
+
+public void println(int i) {
+print(i);
+println();
+}
+
+
+public void println(long l) {
+print(l);
+println();
+}
+
+
+public void println(float f) {
+print(f);
+println();
+}
+
+
+
DO NOT REPLY [Bug 14658] - Bad exception handling in getWriter()
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=14658. 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=14658 Bad exception handling in getWriter() [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 13:59 --- This has been fixed in CVS (CoyoteWriter now fully reimplements PrintWriter; please test it if you can) and will be available in 4.1.16 and 5.0.1. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java
hgomez 2002/11/20 06:14:20
Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java
Log:
Add Linger support, and add some comments about IP settings for AJP13
Revision ChangesPath
1.16 +64 -6
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connector.java
Index: Ajp13Connector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connector.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- Ajp13Connector.java 21 Apr 2002 23:17:48 - 1.15
+++ Ajp13Connector.java 20 Nov 2002 14:14:20 - 1.16
@@ -196,6 +196,13 @@
/**
+ * Linger value to be used on socket close.
+ * Note : a value of -1 means no linger used on close.
+ */
+private int connectionLinger = -1;
+
+
+/**
* The port number on which we listen for ajp13 requests.
*/
private int port = 8009;
@@ -309,7 +316,7 @@
/**
* Set the connection timeout for this Connector.
*
- * @param count The new connection timeout
+ * @param connectionTimeout The new connection timeout
*/
public void setConnectionTimeout(int connectionTimeout) {
@@ -317,6 +324,27 @@
}
+/**
+ * Return the connection linger settings for this Connector.
+ */
+public int getConnectionLinger() {
+
+ return (connectionLinger);
+
+}
+
+
+/**
+ * Set the connection linger for this Connector.
+ *
+ * @param connectionLinger The new connection linger
+ */
+public void setConnectionLinger(int connectionLinger) {
+
+ this.connectionLinger = connectionLinger;
+
+}
+
public void setSecret( String s ) {
secret=s;
}
@@ -844,9 +872,39 @@
logger.log(accepted socket, assigning to processor.);
}
-socket.setSoLinger(true, 100);
+/* Warning :
+ *
+ * To be able to close more quickly a connection, it's recommanded
+ * to set linger to a small value.
+ *
+ * AJP13 connection SHOULD be closed under webserver responsability
and
+ * in such case it's safe to close socket on Tomcat side without
delay,
+ * which may be also the case for HTTP connectors.
+ *
+ * I (henri) recommand to set Linger to 0, making socket closed
immediatly
+ * so the OS will free faster the underlying io descriptor and
resources.
+ * It's very important under heavy load !
+ */
+
+if (connectionLinger 0)
+ socket.setSoLinger(false, 0);
+else
+ socket.setSoLinger(true, connectionLinger);
+
socket.setKeepAlive(true);
+/* Warning :
+ *
+ * AJP13 shouldn't use socket timeout on tomcat site since
+ * when Tomcat close a connection after a timeout is reached
+ * the socket stay in half-closed state until the webserver
+ * try to send a request to tomcat and detect the socket close
+ * when it will try to read the reply.
+ *
+ * On many Unix platforms the write() call didn't told
+ * webserver that the socket is closed.
+ */
+
if (connectionTimeout = 0) {
socket.setSoTimeout(connectionTimeout);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ChannelSocket.java
hgomez 2002/11/20 06:16:46
Modified:jk/java/org/apache/jk/common ChannelSocket.java
Log:
When a socket timeout exception appears
(why set timeout for ajp13 connections ?), the socket is not closed,
and even if tomcat remove the thread the socket is still open and make
webserver stuck while waiting replies to request which are no more monitored
Revision ChangesPath
1.26 +18 -4
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
Index: ChannelSocket.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- ChannelSocket.java31 Oct 2002 00:54:57 - 1.25
+++ ChannelSocket.java20 Nov 2002 14:16:46 - 1.26
@@ -554,14 +554,28 @@
break;
}
}
-this.close( ep );
} catch( Exception ex ) {
-if( ex.getMessage().indexOf( Connection reset ) =0 ) {
+if( ex.getMessage().indexOf( Connection reset ) =0 ||
+ex.getMessage().indexOf( Read timed out ) =0 )
log.info( Server has been restarted or reset this connection);
-} else {
+else
+log.error( Error, processing connection, ex);
+}
+ finally {
+
+ /*
+ * Whatever happened to this connection (remote closed it, timeout,
read error)
+ * the socket SHOULD be closed, or we may be in situation where the
webserver
+ * will continue to think the socket is still open and will forward
request
+ * to tomcat without receiving ever a reply
+ */
+try {
+this.close( ep );
+}
+catch( Exception ex) {
log.error( Error, closing connection, ex);
}
-}
+ }
}
public int invoke( Msg msg, MsgContext ep ) throws IOException {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Javac memory leak
Does anyone know if the javac memory leak still exists (1.4.1 docs say it does not). I have a test the goes through a bunch of jsp pages and if they are not precompiled I get a out of memory exception. Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Javac memory leak
I haven't seen the memory leak on solaris or windows, but isn't the leak only on linux? I thought jasper2 fixes the problem with com.sun.tools.javac.Main since it uses the system native javac? peter John Trollinger wrote: Does anyone know if the javac memory leak still exists (1.4.1 docs say it does not). I have a test the goes through a bunch of jsp pages and if they are not precompiled I get a out of memory exception. Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Javac memory leak
We are using Tomcat 4.1.12 on windows and when running an automated test that navigates through a set of about 75 jsp pages (they have includes in them that kick of more compiles) it gets a OutOfMemoryException halfway through the compile. Our system is quite complex so I don't know if I can get an example of this.. John -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 9:43 AM To: Tomcat Developers List Subject: Re: Javac memory leak I haven't seen the memory leak on solaris or windows, but isn't the leak only on linux? I thought jasper2 fixes the problem with com.sun.tools.javac.Main since it uses the system native javac? peter John Trollinger wrote: Does anyone know if the javac memory leak still exists (1.4.1 docs say it does not). I have a test the goes through a bunch of jsp pages and if they are not precompiled I get a out of memory exception. Thanks, John -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Javac memory leak
Hmm, that sounds bizzare. I'm been using/testing 4.1.10-4.1.12 on both solaris and windows with jdk1.4.1. I've ran several stress test using JMeter simulating light to medium (64 concurrent connections) load for 1-10K requests without any problems. My pages are heavy on JSTL, so they are fairly heavy weight. Even when I run stress tests with 5K unique requests for 10K+ requests, I haven't seen memory leaks. the number of JSP range in 100-200 range. peter John Trollinger wrote: We are using Tomcat 4.1.12 on windows and when running an automated test that navigates through a set of about 75 jsp pages (they have includes in them that kick of more compiles) it gets a OutOfMemoryException halfway through the compile. Our system is quite complex so I don't know if I can get an example of this.. John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Javac memory leak
If the pages are precompiled I do not have any problems at all, it is only when the jsp cache has been deleted that this shows up. John -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 9:57 AM To: Tomcat Developers List Subject: Re: Javac memory leak Hmm, that sounds bizzare. I'm been using/testing 4.1.10-4.1.12 on both solaris and windows with jdk1.4.1. I've ran several stress test using JMeter simulating light to medium (64 concurrent connections) load for 1-10K requests without any problems. My pages are heavy on JSTL, so they are fairly heavy weight. Even when I run stress tests with 5K unique requests for 10K+ requests, I haven't seen memory leaks. the number of JSP range in 100-200 range. peter John Trollinger wrote: We are using Tomcat 4.1.12 on windows and when running an automated test that navigates through a set of about 75 jsp pages (they have includes in them that kick of more compiles) it gets a OutOfMemoryException halfway through the compile. Our system is quite complex so I don't know if I can get an example of this.. John -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/jni jk_jni_aprImpl.c
mturk 2002/11/20 07:03:19 Modified:jk/native2/jni jk_jni_aprImpl.c Log: Fix the POST data. The reply buffer shuld containg the endpoint's post message. Revision ChangesPath 1.42 +1 -1 jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c Index: jk_jni_aprImpl.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- jk_jni_aprImpl.c 25 Sep 2002 08:02:58 - 1.41 +++ jk_jni_aprImpl.c 20 Nov 2002 15:03:18 - 1.42 @@ -502,7 +502,7 @@ /* ep-reply-pos, ep-reply-len , ep-reply-buf ); */ ep-reply-end( env, ep-reply ); -(*jniEnv)-SetByteArrayRegion( jniEnv, data, 0, ep-reply-len + 4 , (jbyte *)ep-reply-buf ); +(*jniEnv)-SetByteArrayRegion( jniEnv, data, 0, ep-post-len + 4 , (jbyte *)ep-post-buf ); rc=JK_OK; } } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Javac memory leak
by any chance do you have multiple webapps or just one? in my case, I only have one webapp which has some services it loads when tomcat starts. All of my pages are dynamic with all the text in resourceBundles. The dynamic data is retrieved from a middle layer in XML format. JSTL is used to get text from resourceBundles and parse the XML. I'm on win2K also. peter John Trollinger wrote: If the pages are precompiled I do not have any problems at all, it is only when the jsp cache has been deleted that this shows up. John -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 9:57 AM To: Tomcat Developers List Subject: Re: Javac memory leak Hmm, that sounds bizzare. I'm been using/testing 4.1.10-4.1.12 on both solaris and windows with jdk1.4.1. I've ran several stress test using JMeter simulating light to medium (64 concurrent connections) load for 1-10K requests without any problems. My pages are heavy on JSTL, so they are fairly heavy weight. Even when I run stress tests with 5K unique requests for 10K+ requests, I haven't seen memory leaks. the number of JSP range in 100-200 range. peter John Trollinger wrote: We are using Tomcat 4.1.12 on windows and when running an automated test that navigates through a set of about 75 jsp pages (they have includes in them that kick of more compiles) it gets a OutOfMemoryException halfway through the compile. Our system is quite complex so I don't know if I can get an example of this.. John -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Javac memory leak
We have 2, one is webdav and the other is our actual application. We use a lot of custom tags and a lot of both types of includes (when I say a lot we have jsp pages that include over 500 other jsp pages, and no, this is not my design :) ) -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 10:12 AM To: Tomcat Developers List Subject: Re: Javac memory leak by any chance do you have multiple webapps or just one? in my case, I only have one webapp which has some services it loads when tomcat starts. All of my pages are dynamic with all the text in resourceBundles. The dynamic data is retrieved from a middle layer in XML format. JSTL is used to get text from resourceBundles and parse the XML. I'm on win2K also. peter John Trollinger wrote: If the pages are precompiled I do not have any problems at all, it is only when the jsp cache has been deleted that this shows up. John -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 9:57 AM To: Tomcat Developers List Subject: Re: Javac memory leak Hmm, that sounds bizzare. I'm been using/testing 4.1.10-4.1.12 on both solaris and windows with jdk1.4.1. I've ran several stress test using JMeter simulating light to medium (64 concurrent connections) load for 1-10K requests without any problems. My pages are heavy on JSTL, so they are fairly heavy weight. Even when I run stress tests with 5K unique requests for 10K+ requests, I haven't seen memory leaks. the number of JSP range in 100-200 range. peter John Trollinger wrote: We are using Tomcat 4.1.12 on windows and when running an automated test that navigates through a set of about 75 jsp pages (they have includes in them that kick of more compiles) it gets a OutOfMemoryException halfway through the compile. Our system is quite complex so I don't know if I can get an example of this.. John -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Javac memory leak
John Trollinger wrote: We have 2, one is webdav and the other is our actual application. We use a lot of custom tags and a lot of both types of includes (when I say a lot we have jsp pages that include over 500 other jsp pages, and no, this is not my design :) ) I'm guessing there's some memory leak in one of the custom tags some where. early in the development of the project I did have memory leaks, but it was a bug in our code. Once I looked at the number of threads running and the GC output, it was obvious our custom tag was the cause. In my particular case, the connection to the middle layer wasn't getting garbaged immediately. Once I fixed that, my memory leak went away. could be something as simple as a tag.release() not releasing correctly :) peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Javac memory leak
But that would not account for the leak only occuring when pages need a compile. If the pages are compiled I never see the leak. -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 10:43 AM To: Tomcat Developers List Subject: Re: Javac memory leak John Trollinger wrote: We have 2, one is webdav and the other is our actual application. We use a lot of custom tags and a lot of both types of includes (when I say a lot we have jsp pages that include over 500 other jsp pages, and no, this is not my design :) ) I'm guessing there's some memory leak in one of the custom tags some where. early in the development of the project I did have memory leaks, but it was a bug in our code. Once I looked at the number of threads running and the GC output, it was obvious our custom tag was the cause. In my particular case, the connection to the middle layer wasn't getting garbaged immediately. Once I fixed that, my memory leak went away. could be something as simple as a tag.release() not releasing correctly :) peter -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Javac memory leak
you never know. if it's a slow leak, precompiled pages may not exhibit the leak. I only discovered the leak in our custom tag when I put the app under moderate/medium load. Under light load the bug wasn't apparent. I'm guessing if you hit each page individuall slowly, the bug doesn't appear. If that's the case, a slow leak may be cause. in my case a slow leak + load was required to expose the bug. peter John Trollinger wrote: But that would not account for the leak only occuring when pages need a compile. If the pages are compiled I never see the leak. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/jni jk_jni_aprImpl.c
mturk 2002/11/20 08:40:10 Modified:jk/native2/jni jk_jni_aprImpl.c Log: Revert the usage of post msg. Use the suplied reply, and fix the 4 byte out-of-bounds exception Revision ChangesPath 1.43 +1 -1 jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c Index: jk_jni_aprImpl.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c,v retrieving revision 1.42 retrieving revision 1.43 diff -u -r1.42 -r1.43 --- jk_jni_aprImpl.c 20 Nov 2002 15:03:18 - 1.42 +++ jk_jni_aprImpl.c 20 Nov 2002 16:40:10 - 1.43 @@ -502,7 +502,7 @@ /* ep-reply-pos, ep-reply-len , ep-reply-buf ); */ ep-reply-end( env, ep-reply ); -(*jniEnv)-SetByteArrayRegion( jniEnv, data, 0, ep-post-len + 4 , (jbyte *)ep-post-buf ); +(*jniEnv)-SetByteArrayRegion( jniEnv, data, 0, ep-reply-len, (jbyte *)ep-reply-buf ); rc=JK_OK; } } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_handler_response.c
mturk 2002/11/20 08:41:15
Modified:jk/native2/common jk_handler_response.c
Log:
Use the supplied msg instead of directly referencing
endpoint's post msg. That fixex the JNI post readings.
Revision ChangesPath
1.25 +1 -2
jakarta-tomcat-connectors/jk/native2/common/jk_handler_response.c
Index: jk_handler_response.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_handler_response.c,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- jk_handler_response.c 11 Nov 2002 15:40:34 - 1.24
+++ jk_handler_response.c 20 Nov 2002 16:41:15 - 1.25
@@ -227,7 +227,6 @@
jk_endpoint_t *ae, jk_msg_t *msg )
{
jk_ws_service_t *r=target;
-jk_msg_t *post = ae-post;
int len = msg-getInt(env, msg);
if(len AJP13_MAX_SEND_BODY_SZ) {
@@ -243,7 +242,7 @@
/* env-l-jkLog(env, env-l, JK_LOG_INFO, */
/* handler_request.getChunk() - read len=%d\n,len); */
-len=post-appendFromServer( env, post, r, ae, len );
+len=msg-appendFromServer( env, msg, r, ae, len );
/* the right place to add file storage for upload */
if (len = 0) {
r-content_read += len;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14714] New: - Problem with encodeURL() and Refresh tags/header
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=14714. 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=14714 Problem with encodeURL() and Refresh tags/header Summary: Problem with encodeURL() and Refresh tags/header Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The problem arises when you want to use a URL that has been encoded by HttpServletResponse.encodeURL() with either a Refresh header or a Refresh meta tag. Netscape/Mozilla seem to work, but IE 4.x, 5.x, 6.x looses the session if cookies are turned off. To make an example: I need to reload a certain page (or a different page) after some period of time. I use a meta-tag meta http-equiv=refresh content=30; URL=http://my.server.com/my/servlet;jsessionid=WHATEVER?id=1234; The problem is the ; in the URL. IE seems to stop parsing and does not submit the session id. While I have seen that this is some kind of general problem servlet containers have, the usual workaround, submitting the session id as ordinary request parameter, does no longer work with Tomcat. I think that it worked with previous versions. Even quoting the URL does not solve the problem. Other people may experience similar problems if they want to use such an URL in JavaScript. No, encodeRedirectURL() does not work, either. PS: For me, the severity would be at least major, I just didn't want to escalate the thing too much. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Javac memory leak
I also have no memory leak problems now with Tomcat 4.1.12. But i'm using jikes instead of javac as jsp page compiler. Whats about switching to jikes. If the memory leak problem is gone with jikes, javac still leaks memory, otherwise it is a problem in the jsp pages. Cheers Holger - Original Message - From: John Trollinger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 20, 2002 3:39 PM Subject: Javac memory leak Does anyone know if the javac memory leak still exists (1.4.1 docs say it does not). I have a test the goes through a bunch of jsp pages and if they are not precompiled I get a out of memory exception. Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_workerEnv.c jk_handler_response.c
mturk 2002/11/20 09:25:41
Modified:jk/native2/common jk_workerEnv.c jk_handler_response.c
Log:
For stream channels (sockets) use the supplied msg for
getChunk handler.
Revision ChangesPath
1.58 +2 -2 jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c
Index: jk_workerEnv.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- jk_workerEnv.c11 Nov 2002 15:40:34 - 1.57
+++ jk_workerEnv.c20 Nov 2002 17:25:41 - 1.58
@@ -525,7 +525,7 @@
msg-dump( env, msg, Apache-tomcat );
rc = ep-worker-channel-send(env, ep-worker-channel, ep,
- ep-post );
+ msg );
if (rc 0) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
ajp14.processCallbacks() error sending response
data\n);
1.26 +1 -0
jakarta-tomcat-connectors/jk/native2/common/jk_handler_response.c
Index: jk_handler_response.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_handler_response.c,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- jk_handler_response.c 20 Nov 2002 16:41:15 - 1.25
+++ jk_handler_response.c 20 Nov 2002 17:25:41 - 1.26
@@ -241,6 +241,7 @@
/* env-l-jkLog(env, env-l, JK_LOG_INFO, */
/* handler_request.getChunk() - read len=%d\n,len); */
+msg-reset(env, msg);
len=msg-appendFromServer( env, msg, r, ae, len );
/* the right place to add file storage for upload */
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ajp13 errors
I'm running a webmail aplication on tomcat4.1.10 + apache2.0.34 + mod_jk2 when a user breaks the browser connection while downloading data (=mail attachment) from tomcat i get the following error on the apache side: [Wed Nov 20 18:03:24 2002] [error] Error ajp_process_callback - write failed [Wed Nov 20 18:03:24 2002] [error] ajp13.service() ajpGetReply unrecoverable error 3 [Wed Nov 20 18:03:24 2002] [error] ajp13.service() Error forwarding ajp13:localhost:8009 [Wed Nov 20 18:03:24 2002] [error] mod_jk.handler() Error connecting to tomcat 12 After the first error many more will follow, without the user breaking connections. Isn't it possible for the worker to reinitialize after a severe error? (Maybe through jk2_worker_ajp13_destroy/init?) Jacco -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_msg_ajp.c
mturk 2002/11/20 09:29:11 Modified:jk/native2/common jk_msg_ajp.c Log: Use the logger for dump method instead of using stderr. Revision ChangesPath 1.20 +2 -1 jakarta-tomcat-connectors/jk/native2/common/jk_msg_ajp.c Index: jk_msg_ajp.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_msg_ajp.c,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- jk_msg_ajp.c 24 Sep 2002 22:39:21 - 1.19 +++ jk_msg_ajp.c 20 Nov 2002 17:29:11 - 1.20 @@ -130,7 +130,8 @@ } *current++='\n'; *current++='\0'; -fprintf( stderr, %.4x%s, i, line ); +env-l-jkLog(env, env-l, JK_LOG_INFO, + %.4x%s, i, line); } } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK2 module for AOLserver
Alexander Leyke wrote: Costin Manolache wrote: In jk2 we use ajp13 for all channels, including JNI. That allows us to reuse the buffers and avoid object allocations from C - which improves a lot the performance of the code ( we also avoid a lot of expensive calls, etc ). Same technique is also used (AFAIK) in mozilla bridge. Do you mean ajp13 channel would work with in-process worker? Ajp13 protocol ( marshalling, etc ) is used for in-process communication and out of process communication. By marshalling the data we avoid some expensive and complex JNI operations, and benefit of all optimizations done on java side ( and the code is simpler ). The worker_jni code is just used to start tomcat in-process, but not for request forwarding. The JNI channel is special because it is single-threaded ( a doors channel will use the same type of code ), and that has some implications in how the request is processed - but the data encoding is the same. Let me rephrase my initial question. I am interested in Tomcat executing in-process. If JNI worker cannot be used, what alternative do I have to run Tomcat in-process? Is JNI worker permanently out or will be re-enabled in the future (what's the timetable?) The JNI worker is working for IIS and Apache2, I see no reason why it won't work with AOLserver. ( I suppose you're aware of the jk1 AOLserver connector - it also used JNI, so you shouldn't have any major problems ) Just get the socket to work ( it's easier to debug the server-specific code), then enable the jni channel and worker. In case I am out-of luck with in-process Tomcat g, what is the highest performance alternative for a Web server to talk to Tomcat 4? You could use unix channel. Or ( if on solaris ) implement a doors channel ( most of the tricks for making it work are already done for JNI - i.e. single threaded communication ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: ajp13 errors
-Original Message- From: Jacco Braat [Wed Nov 20 18:03:24 2002] [error] Error ajp_process_callback - write failed [Wed Nov 20 18:03:24 2002] [error] ajp13.service() ajpGetReply unrecoverable error 3 [Wed Nov 20 18:03:24 2002] [error] ajp13.service() Error forwarding ajp13:localhost:8009 [Wed Nov 20 18:03:24 2002] [error] mod_jk.handler() Error connecting to tomcat 12 Yes... we have some problems with that ;) After the first error many more will follow, without the user breaking connections. Well, the entire worker gets to the error state if a single client breaks a connection, instead of endpoint only. Think that the problem is from the forked servers conept, where you have single a worker with a single endpoint. I'll need to make a custom client to be able to test that I'm afraid. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JK2] jni channel doesn't send POST data (WAS: [JK2] Apache2 add read-ahead for POST data)
Mladen Turk wrote: Hi, Apache isn't the bugger here. The jni itself is unable to process the POST data. The channel_jni is invoked for the getChunk (id 6), but then nothing happens (at least I wasn't been able to trace any jni_send). It invokes the response dispatcher, but then nothing happens. (Think that this message should be written back as requested) like for stream channels in the processCallbacks. Now I can check for JK_HANDLER_RESPONSE after calling dispatch and write the post data, but that doesn't help. The message is formatted correctly, but seems like Java part disregards that. Am I missing something here? Costin? It's most likely a bug. I know Nacho is using JNI with IIS - and the code looks fine. This week I'll not be able to help too much, I am far too busy, but I'll try finding some time during the weekend. Costin MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Nightly TC 3.3.x builds not working anymore?
We could use the gump-generated builds. ( it seems we just need to zip the build tree and add a symlink ) Costin Larry Isaacs wrote: Hi Hans, The 3.3.x nightly is currently run by hand so that the zips are built on Windows and the tar.gzs are build under Unix. I typically update it after I see changes come through. I'll run another build to get things more current, in case I have missed something. I hope to start helping more soon on the various Tomcats, but to this point a recent task assignment in my day job has kept me very busy. Cheers, Larry -Original Message- From: Hans Schmid [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 5:51 AM To: Tomcat Developers List Subject: AW: Nightly TC 3.3.x builds not working anymore? Last time they were created was 08-Nov-2002 but today is the 20.11.2002 ;) http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3.x/ Parent Directory - JmxSupport.war 08-Nov-2002 06:28 459K PasswordPrompter.war08-Nov-2002 06:28 23K StreamHandler.war 08-Nov-2002 06:28 9.4K jakarta-tomcat-3.3.2-dev-src.tar.gz 08-Nov-2002 06:07 2.9M GZIP compressed file jakarta-tomcat-3.3.2-dev-src.zip08-Nov-2002 05:22 3.1M jakarta-tomcat-3.3.2-dev.tar.gz 08-Nov-2002 06:08 5.4M GZIP compressed file jakarta-tomcat-3.3.2-dev.zip08-Nov-2002 05:27 5.5M jsp-tests.war 08-Nov-2002 06:28 318K servlet-tests.war 08-Nov-2002 06:28 1.8M test.war08-Nov-2002 06:28 165K -Ursprungliche Nachricht- Von: Henri Gomez [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 20. November 2002 10:41 An: Tomcat Developers List Betreff: Re: Nightly TC 3.3.x builds not working anymore? Hans Schmid wrote: Hi, the nightly build of Tomcat 3.3.x seems to have stopped at 08-Nov-2002. Any Idea, why? Cheers, Hans -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] What's the error ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8763] - Web app libraries (log4j.jar) remain locked after web apps' stop / remove
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=8763. 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=8763 Web app libraries (log4j.jar) remain locked after web apps' stop / remove [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 19:06 --- I don't see that 4.1.12 resolved this issue. All jars in the webapps WEB_INF/lib directory are still locked after removing the app. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [JK2] jni channel doesn't send POST data (WAS: [JK2] Apache2 add read-ahead for POST data)
-Original Message- From: Costin Manolache It's most likely a bug. I know Nacho is using JNI with IIS - and the code looks fine. Yeah, it was... Just fixed it in the cvs. We were sending reply msg and the handler was feeding post msg. Looks fine now (tested with 100K POST data) using either JNI or socket. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
new Performance benchmarks/comparisons on tomcat
http://webperformanceinc.com/library/ServletReport/index.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: new Performance benchmarks/comparisons on tomcat
Hi, Interesting. Thank you for sharing. Yoav Shapira Millennium ChemInformatics -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 2:11 PM To: [EMAIL PROTECTED] Subject: new Performance benchmarks/comparisons on tomcat http://webperformanceinc.com/library/ServletReport/index.html -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Javac memory leak
on 2002/11/20 7:34 AM, John Trollinger [EMAIL PROTECTED] wrote: We have 2, one is webdav and the other is our actual application. We use a lot of custom tags and a lot of both types of includes (when I say a lot we have jsp pages that include over 500 other jsp pages, and no, this is not my design :) ) Yea, most people blame bad JSP design on others. I blame it on Sun. =) -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14718] New: - Trailing slash is required to access our application
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=14718. 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=14718 Trailing slash is required to access our application Summary: Trailing slash is required to access our application Product: Tomcat 4 Version: 4.0 Beta 1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Connector:JK/AJP (deprecated) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Configuration Tomcat 4.0.6. OS: Solaris 8 (SPARC) Web Server: Apache 1.3.27 (jk connector using AJP 1.3 protocol) Java VM: Sun SDK 1.3.1_05 HotSpot After installing our portal Application on Tomcat 406, when we we try to access http://sun57.lab.epicentric.com/portal/console is showing The page cannot be displayed. / is not being added after the console and works fine if we try to access like http://sun57.lab.epicentric.com/portal/console/ More details is as below : Given the web.xml that currently ships wih our application portal, mod_jk auto- generate the following config: JkMount /portal/console/* ajp13 This allows access to the server console through: http://sun57.lab.epicentric.com/portal/console/ but not http://sun57.lab.epicentric.com/portal/console The workaround is to modify EFS web.xml to include the following mappings: servlet-mapping servlet-nameSiteDispatcherServlet/servlet-name url-pattern/console/*/url-pattern /servlet-mapping servlet-mapping servlet-nameSiteDispatcherServlet/servlet-name url-pattern/console/url-pattern /servlet-mapping mod_jk then auto generate the following apache config: JkMount /portal/console ajp13 JkMount /portal/console/* ajp13 and the server console can be accessed either by: http://sun57.lab.epicentric.com/portal/console or http://sun57.lab.epicentric.com/portal/console/ auto-generation of mod_kj.conf not generating comprehensive mappings). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Does anyone care....
... about the IIS connector? Every post that I have made with respect to it has been more or less ignored over the last couple of weeks. First when I reported the problem and asked for advice on how I might implement a solution. Then when I implemented a solution without advice and posted the patch, and most recently when I asked about the suitability and status of my patch. What do I have to do to get some support? I'm willing to follow any protocol that is required... I would just appreciate not having to apply my patch every time I upgrade the connector to the latest official version. Thanks .-.| Steven Velez oo|| Software Engineer /`'\| alventive (\_;/) | 678-202-2226
RE: Does anyone care....
Steven, I normally do care of the IIS connector, sorry for not being quick but as everyone i'm overloaded, your change althought optional is big and until yesterday i did not reviewed it, and i'll plan to apply it asap.. If someone can take it and apply, ok from me, but as everybody here apply something without at least compiling and testing it makes me very nervous, and i suppouse other committers feel the same.. ... about the IIS connector? Every post that I have made with respect to it has been more or less ignored over the last couple of weeks. First when I reported the problem and asked for advice on how I might implement a solution. Then when I implemented a solution without advice and posted the patch, and most recently when I asked about the suitability and status of my patch. Nothing cares about your problems mainly because they are you problems, you are the most interested in them, sooo :).. the real reason is that the IIS connector in his old jk1 version is only touched by a small subset of committers, me in between them, and we all are very very busy atm, sorry.., but that's life.. What do I have to do to get some support? I'm willing to follow any protocol that is required... I would just appreciate not having to apply my patch every time I upgrade the connector to the latest official version. Steven, the jk1 IIS connector it's freezed from many many time ago.. so it cannot be that hard to follow the development.. ;) and you have learned the protocol very well, maybe a bug with the patch as an attachment could do the trick ;).. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ContextConfig tldConfigJar IOException
Using 4.0.6 I'm getting a lot of exceptions (for every jar in /WEB-INF/lib/) on startup like this one: ContextConfig[]: tldConfigJar(/WEB-INF/lib/xerces.jar): java.io.IOException: No such file or directory Which is problematic because if an exception happens in tldConfigJar(), ContextConfig in 4.0.6 calls jarFile.close(), which apparently causes classloader issues... and we're having classloader problems. So what's causing this IOException? I can't tell for the life of me--all the permissions on the directory and its parents look fine. Our other instances using 4.0.6 don't have this problem. Any suggestions? Nick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Does anyone care....
Ignacio, Thanks for the reply. I'm sorry that my e-mail sounded a bit edgy, but I felt it had to be that way to get some info back. I know that people can get busy at times (I did not know the state of your personal work load at the moment) so take your time. I was mostly concerned about not getting any info about where the review process was, but you have now answered that question, and I thank you. As far as JK1 vs. JK2 goes, is the JK2 connector ready? I seem to remember reading some docs in the source tree generally stating that since the jk2 stuff is not as seasoned as the jk1 stuff, an upgrade is not recommended for production systems so I am sticking with jk1. What is/will be the benefit of switching? Whenever it is felt that the connector is ready for mass use, I will be upgrading. I will also be willing to merge my changes in to jk2. Do you think it's better to do this sooner or later? With respect to your last comment: Is submitting patches as incidents in bugzilla preferred to posting them on the mailing list? If so, I will do this in the future. Thank you very much. .-.| Steven Velez oo|| Software Engineer /`'\| alventive (\_;/) | 678-202-2226 -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 4:29 PM To: 'Tomcat Developers List' Subject: RE: Does anyone care Steven, I normally do care of the IIS connector, sorry for not being quick but as everyone i'm overloaded, your change althought optional is big and until yesterday i did not reviewed it, and i'll plan to apply it asap.. If someone can take it and apply, ok from me, but as everybody here apply something without at least compiling and testing it makes me very nervous, and i suppouse other committers feel the same.. ... about the IIS connector? Every post that I have made with respect to it has been more or less ignored over the last couple of weeks. First when I reported the problem and asked for advice on how I might implement a solution. Then when I implemented a solution without advice and posted the patch, and most recently when I asked about the suitability and status of my patch. Nothing cares about your problems mainly because they are you problems, you are the most interested in them, sooo :).. the real reason is that the IIS connector in his old jk1 version is only touched by a small subset of committers, me in between them, and we all are very very busy atm, sorry.., but that's life.. What do I have to do to get some support? I'm willing to follow any protocol that is required... I would just appreciate not having to apply my patch every time I upgrade the connector to the latest official version. Steven, the jk1 IIS connector it's freezed from many many time ago.. so it cannot be that hard to follow the development.. ;) and you have learned the protocol very well, maybe a bug with the patch as an attachment could do the trick ;).. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ContextConfig tldConfigJar IOException
Figured it out myself! :-) I printed out the IOException stack trace, saw that the error happened when a temp file was being created. Turns out my CATALINA_TMPDIR was set to a non-existing directory. I created it and no more IOExceptions. Now I just hope my classloader issue is fixed... Nick On Wednesday, November 20, 2002, at 05:01 PM, Nick Wesselman wrote: Using 4.0.6 I'm getting a lot of exceptions (for every jar in /WEB-INF/lib/) on startup like this one: ContextConfig[]: tldConfigJar(/WEB-INF/lib/xerces.jar): java.io.IOException: No such file or directory Which is problematic because if an exception happens in tldConfigJar(), ContextConfig in 4.0.6 calls jarFile.close(), which apparently causes classloader issues... and we're having classloader problems. So what's causing this IOException? I can't tell for the life of me--all the permissions on the directory and its parents look fine. Our other instances using 4.0.6 don't have this problem. Any suggestions? Nick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][JASPER2] Simple patch for one of the resource errormessages.
I think that the following error message is incorrect:
- Scripting elements ( %@, %!, %=, % ) are disallowed here.
Since directives (%@) are not scripting elements.
I've attached a patch to correct the messages.properties.
Index: messages.properties
===
RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.60
diff -u -r1.60 messages.properties
--- messages.properties 16 Nov 2002 04:20:10 - 1.60
+++ messages.properties 20 Nov 2002 23:47:23 -
@@ -266,7 +266,7 @@
jsp.error.empty.body.not.allowed=Empty body not allowed for {0}
jsp.error.jspbody.required=Must use jsp:body to specify tag body for {0} if jsp:attribute is used.
jsp.error.jspbody.emptybody.only=The {0} tag can only have jsp:attribute in its body.
-jsp.error.no.scriptlets=Scripting elements ( %@, %!, %=, % ) are disallowed here.
+jsp.error.no.scriptlets=Scripting elements ( %!, %=, % ) are disallowed here.
jsp.error.internal.unexpected_node_type=Internal Error: Unexpected node type encountered
jsp.error.tld.fn.invalid.signature=Invalid syntax for function signature in TLD. Tag Library: {0}, Function: {1}
jsp.error.tld.fn.duplicate.name=Duplicate function name {0} in tag library {1}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Does anyone care....
Steven, JK2 is aproaching Stable state at very good pace, and the help there is much more needed than in jk1, testing and reporting bugs, and implemeting features like yours, is preferred.. in any case yours is ok for jk1.. thought.. in to jk2. Do you think it's better to do this sooner or later? I think sooner the better, mostly i can easily test to your changes in my dev machine ;), and development in jk2 ( native2 ) it's active at the moment, and jk1 it's freezed .. soo With respect to your last comment: Is submitting patches as incidents in bugzilla preferred to posting them on the mailing list? If so, I will do this in the future. Well, you finally seemed to the get the answer by yourself :), but for sure a bug with a [PATCH] in the summary and a good explanation, with the patch attached will do well too, i prefer it, it gets stored ata safe place ( much better than a mail archive ) and we can add comments for posterity.. and the bugzilla mails go to the tomcat-dev too.. so better to add a it as bug.. IMHO.. Thank you very much. Thank you for your patience Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK2 module for AOLserver
Thanks for the reply, Costin. There are some more questions below. Costin Manolache wrote: Ajp13 protocol ( marshalling, etc ) is used for in-process communication and out of process communication. By marshalling the data we avoid some expensive and complex JNI operations, and benefit of all optimizations done on java side ( and the code is simpler ). The worker_jni code is just used to start tomcat in-process, but not for request forwarding. The JNI channel is special because it is single-threaded ( a doors channel will use the same type of code ), and that has some implications in how the request is processed - but the data encoding is the same. Does it mean that in-process worker is a performance bottleneck in single-process server? The JNI worker is working for IIS and Apache2, I see no reason why it won't work with AOLserver. ( I suppose you're aware of the jk1 AOLserver connector - it also used JNI, so you shouldn't have any major problems ) I am aware of nstomcat module which works with Tomcat 3, but not Tomcat 4. There is nothing of that nature under jakarta-tomcat-connectors-4.1.12-src/jk/native. Should I look better? Just get the socket to work ( it's easier to debug the server-specific code), then enable the jni channel and worker. OK, as I am working on it, there are some Java errors from Tomcat startup within AOLserver. I can repeat those errors when running TomcatStarter class from shell command line. :: stderr.log :: TomcatStarter: main() Try org.apache.tomcat.startup.Main Try org.apache.catalina.startup.BootstrapService Starting org.apache.catalina.startup.BootstrapService java.lang.NullPointerException at org.apache.catalina.startup.BootstrapService.start(BootstrapService.java:244) at org.apache.catalina.startup.BootstrapService.main(BootstrapService.java:307) at java.lang.reflect.Method.invoke(Native Method) at org.apache.jk.apr.TomcatStarter.run(TomcatStarter.java:127) at java.lang.Thread.run(Thread.java:484) Created catalinaLoader in: /deleted - AL/jakarta-tomcat-4.1.12/server/lib [INFO] Registry - -Loading registry information [INFO] Registry - -Creating new Registry instance [INFO] Registry - -Creating MBeanServer [INFO] Http11Protocol - -Initializing Coyote HTTP/1.1 on port 8089 java.lang.ArrayIndexOutOfBoundsException at org.apache.catalina.startup.BootstrapService.main(BootstrapService.java:305) at java.lang.reflect.Method.invoke(Native Method) at org.apache.jk.apr.TomcatStarter.run(TomcatStarter.java:127) at java.lang.Thread.run(Thread.java:484) java.lang.ArrayIndexOutOfBoundsException at org.apache.jk.apr.TomcatStarter.run(TomcatStarter.java:131) at java.lang.Thread.run(Thread.java:484) :: stdout.log :: Bootstrap: Starting service TomcatStarter: Done TomcatStarter: Done Your help is always appreciated, Alex -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: problems with SSI extensions
I've been a bad boy by not taking care of this. This is just the kind
of encouragement I need to movitate my guilty butt. I'll work on it
tonight and with any luck commit it tomorrow.
Which branch do I commit this to? And if the answer is the 4.x branch,
who/how does it get forward-ported?
-Dan
Paul Speed wrote:
These worked at one time. Then that entire version of SSI was
clobbered and replaced with a version that only supported a subset
of the commands. None of my clobbered rewrite has been ported
forward again and I haven't had the time (or motivation) to rewrite
my rewrite again and try to get a patch committed.
I only mention this so that if someone wants to scratch this particular
itch they know that there's code in the CVS attic that does this.
They'd just have to port it somehow. Might save someone some time.
-Paul
Richard Hallier wrote:
Hello,
Tomcat 4.1.12 with SSI enabled
Basic functions work well, but i'm in trouble with :
1/ !--#if is not supported (i've got an unknown command), maybe it's
normal
2/ This command in my .shtm : !--#include virtual=${QUERY_STRING} --
generates the following error:
2002-11-19 21:11:20 ssi: #include--Couldn't include file: ${QUERY_STRING}
java.io.IOException: Couldn't find file: /${QUERY_STRING}
Thank you for your help.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14722] New: - Missing/invalid string resource for
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=14722. 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=14722 Missing/invalid string resource for Summary: Missing/invalid string resource for Product: Tomcat 4 Version: 4.1.12 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In LocalStrings*.properties files in org.apache.catalina.session, the following property is incorrect and should be changed from: standardSession.setAttribute.ise=setAttribute: Non-serializable attribute to: standardSession.setAttribute.iae=setAttribute: Non-serializable attribute -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14724] New: - [PATCH] AccessLogValve - %{xxx}i implementation AND disable log rotation
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=14724.
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=14724
[PATCH] AccessLogValve - %{xxx}i implementation AND disable log rotation
Summary: [PATCH] AccessLogValve - %{xxx}i implementation AND
disable log rotation
Product: Tomcat 4
Version: Nightly Build
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
This bug report replaces bug enhancement 12145.
This patch allows for the following:
%{xxx}i xxx is the name of the incoming header
%{xxx}c xxx is the name of a specific cookie
%{xxx}r xxx is an attribute in the ServletRequest
%{xxx}s xxx is an attribute in the HttpSession
For %A - uses InetAddress.getLocalHost() instead of hardcoded 127.0.0.1
Patch also allows access log not be rotated. This is done by adding a new
attribute called rotatable. It defaults to true. If set to false - then the
access log does not rotate. (Which will make a lot of tomcat-users happy)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14724] - [PATCH] AccessLogValve - %{xxx}i implementation AND disable log rotation
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=14724.
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=14724
[PATCH] AccessLogValve - %{xxx}i implementation AND disable log rotation
--- Additional Comments From [EMAIL PROTECTED] 2002-11-21 02:04 ---
Created an attachment (id=3907)
patch file for AccessLogValve.java from cvs
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14725] New: - Examples webapp uses non-serializable session attributes
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=14725. 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=14725 Examples webapp uses non-serializable session attributes Summary: Examples webapp uses non-serializable session attributes Product: Tomcat 4 Version: 4.1.12 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Examples AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Components of examples.war should only use serializable session attributes. (As an aside, IMO the session manager should have its distributable mode enabled by default.) As an example, numguess.jsp stores the currently non- serializable class num.NumberGuessBean in session scope. The standard Tomcat session does not even persist the non-serializable attributes (and silently skips them if the manager is not declared to be distributable). This should be the example for which others should code their apps by. The examples webapp should thus attempt to store session attributes that are always serializable. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12145] - [PATCH] AccessLogValve - %{xxx}i implementation
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=12145.
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=12145
[PATCH] AccessLogValve - %{xxx}i implementation
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||DUPLICATE
--- Additional Comments From [EMAIL PROTECTED] 2002-11-21 02:05 ---
Closing this bug and putting new info into bug 14724.
*** This bug has been marked as a duplicate of 14724 ***
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14724] - [PATCH] AccessLogValve - %{xxx}i implementation AND disable log rotation
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=14724.
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=14724
[PATCH] AccessLogValve - %{xxx}i implementation AND disable log rotation
--- Additional Comments From [EMAIL PROTECTED] 2002-11-21 02:05 ---
*** Bug 12145 has been marked as a duplicate of this bug. ***
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Disable access log rotation
Is anyone opposed to looking at bug 14724? It replaces a similiar enhancment [bug 12145](with patch) logged a few months ago. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14724 The patch also enables writing out Cookies, incoming headers, Session attributes, and HttpServletRequest attributes in a syntax similar to apache. If this functionality is added to the admin app, I believe the following needs added to mbeans-descriptors.xml in the AccessLogValve section. attribute name=rotatable description=Rotate log is=true type=boolean/ -Tim -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JkCoyoteHandler does not respect port attribute in server.xml
Did anyone notice that Tomcat 4.1.12 does not respect the port attribute for the AJP13 connector I have a connector defined like this, Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8010 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8444 acceptCount=10 debug=0 connectionTimeout=2 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ and yet, tomcat starts the connector on port 8009. any thoughts? Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 6:19 PM To: [EMAIL PROTECTED] Subject: [PATCH] Disable access log rotation Is anyone opposed to looking at bug 14724? It replaces a similiar enhancment [bug 12145](with patch) logged a few months ago. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14724 The patch also enables writing out Cookies, incoming headers, Session attributes, and HttpServletRequest attributes in a syntax similar to apache. If this functionality is added to the admin app, I believe the following needs added to mbeans-descriptors.xml in the AccessLogValve section. attribute name=rotatable description=Rotate log is=true type=boolean/ -Tim -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JkCoyoteHandler does not respect port attribute in server.xml
I believe it's a bug. You can get around it by defining the port in conf/jk2.properties ... http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk2/configtcex.html On Wednesday, November 20, 2002, at 08:26 PM, Filip Hanik wrote: Did anyone notice that Tomcat 4.1.12 does not respect the port attribute for the AJP13 connector I have a connector defined like this, Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8010 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8444 acceptCount=10 debug=0 connectionTimeout=2 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ and yet, tomcat starts the connector on port 8009. any thoughts? Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 6:19 PM To: [EMAIL PROTECTED] Subject: [PATCH] Disable access log rotation Is anyone opposed to looking at bug 14724? It replaces a similiar enhancment [bug 12145](with patch) logged a few months ago. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14724 The patch also enables writing out Cookies, incoming headers, Session attributes, and HttpServletRequest attributes in a syntax similar to apache. If this functionality is added to the admin app, I believe the following needs added to mbeans-descriptors.xml in the AccessLogValve section. attribute name=rotatable description=Rotate log is=true type=boolean/ -Tim -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_workerEnv.c jk_worker_lb.c
mturk 2002/11/20 23:46:41
Modified:jk/native2/common jk_workerEnv.c jk_worker_lb.c
Log:
Fix the client aborted connections.
Instead of setting the entire worker to a error state, check the service
return value, and if it is set to the JK_HANDLER_ERROR, close the
connection to TC and skip other workers, cause the client is disconnected
already.
Revision ChangesPath
1.59 +2 -1 jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c
Index: jk_workerEnv.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c,v
retrieving revision 1.58
retrieving revision 1.59
diff -u -r1.58 -r1.59
--- jk_workerEnv.c20 Nov 2002 17:25:41 - 1.58
+++ jk_workerEnv.c21 Nov 2002 07:46:40 - 1.59
@@ -537,6 +537,7 @@
/* Normal error ( for example writing to the client failed ).
* The ajp connection is still in a stable state.
*/
+ep-recoverable = JK_TRUE;
return rc;
case JK_HANDLER_FATAL:
/*
1.27 +10 -2 jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c
Index: jk_worker_lb.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- jk_worker_lb.c14 Oct 2002 06:30:42 - 1.26
+++ jk_worker_lb.c21 Nov 2002 07:46:41 - 1.27
@@ -424,7 +424,7 @@
}
return JK_OK;
}
-
+
if (rec-mbean-initialize lb-cs != NULL) {
time_t now = time(NULL);
/* In the case of initialization timeout disable the worker */
@@ -444,8 +444,16 @@
continue;
}
}
+/* If this is a browser connection error dont't check other
+ * workers.
+ */
+if (rc == JK_HANDLER_ERROR) {
+
+return JK_HANDLER_ERROR;
+}
+
env-l-jkLog(env, env-l, JK_LOG_ERROR,
- lb.service() worker failed %s\n, rec-mbean-name );
+ lb.service() worker failed %d for %s\n, rc,
rec-mbean-name );
/*
* Service failed !!!
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
