Re: Bug 13658
Bill Barker wrote: Before I start performing major surgery on the TC4/5 connector, I wanted to check on what is the reason for having the attributes field in CoyoteRequest (instead of just delegating to the o.a.c.Request like the 3.3 Adapter does). At the moment, the SSL request attributes are set on the o.a.c.Request (because that's all that the Action knows about). This is Ok for getAttribute, since it delegates when not found. But for getAttributeNames, it only uses the names known to the attributes field (so no SSL attributes). My strong preference is to delegate always (cleaner, esp. for TC 5 that will be able to access Coyote directly). But I can fix this particular bug either way. I don't remember the reason. I probably chose not to delegate since there might not have been any attributes ariginally in the Coyote Request object. So it wasn't done because it wasn't there; I don't think there ever was a Good Reason (TM) for that. +1 to fix it. What's the surgery you want to do ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
remm2002/10/19 02:30:37
Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Log:
- Attempts to address bug 13736.
- Add code for recovery if the serverSocket dies. Needs testing (I tested with
an exception thrown according to a random value after the socket has been
accepted, and it *seems* to work).
- There was similar code in Tomcat 4.0, and it is not needed unless there's
a huge amount of accepts being made. It is also likely caused by JVM's
network code deficiencies. If running on Unix without root on 80, recovery is
not possible.
Revision ChangesPath
1.5 +56 -36
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.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- PoolTcpEndpoint.java 16 May 2002 18:57:39 - 1.4
+++ PoolTcpEndpoint.java 19 Oct 2002 09:30:37 - 1.5
-102,6 +102,8
private static final int BACKLOG = 100;
private static final int TIMEOUT = 1000;
+private final Object threadSync = new Object();
+
private boolean isPool = true;
private int backlog = BACKLOG;
-312,11 +314,14
s.setSoLinger(true, 0);
}
s.close();
- // System.out.println(Closing socket + port );
- serverSocket.close(); // XXX?
} catch(Exception e) {
log(Caught exception trying to unlock accept., e);
}
+ try {
+ serverSocket.close();
+ } catch(Exception e) {
+log(Caught exception trying to close socket., e);
+ }
serverSocket = null;
}
}
-325,6 +330,7
Socket acceptSocket() {
Socket accepted = null;
+
try {
if (running) {
if(null!= serverSocket) {
-343,48 +349,62
if( factory != null accepted != null)
factory.initSocket( accepted );
}
- }
+ }
}
catch(InterruptedIOException iioe) {
// normal part -- should happen regularly so
// that the endpoint can release if the server
// is shutdown.
}
- catch (SocketException e) {
+ catch (IOException e) {
+
+ if (running) {
- // TCP stacks can throw SocketExceptions when the client
- // disconnects. We don't want this to shut down the
- // endpoint, so ignore it. Is there a more robust
- // solution? Should we compare the message string to
- // Connection reset by peer?
-
- // socket exceptions just after closing endpoint (when
- // running=false) aren't even logged
- if (running != false) {
String msg = sm.getString(endpoint.err.nonfatal,
serverSocket, e);
- log(msg, e, Log.INFORMATION);
- }
+ log(msg, e, Log.ERROR);
- }
-
- // Future developers: if you identify any other nonfatal
- // exceptions, catch them here and log as above
+if (accepted != null) {
+try {
+accepted.close();
+accepted = null;
+} catch(Exception ex) {
+msg = sm.getString(endpoint.err.nonfatal,
+ accepted, ex);
+log(msg, ex, Log.INFORMATION);
+}
+}
+// Restart endpoint when getting an IOException during accept
+synchronized (threadSync) {
+try {
+serverSocket.close();
+} catch(Exception ex) {
+msg = sm.getString(endpoint.err.nonfatal,
+ serverSocket, ex);
+log(msg, ex, Log.INFORMATION);
+}
+serverSocket = null;
+try {
+if (inet == null) {
+serverSocket = factory.createSocket(port, backlog);
+} else {
+serverSocket =
+factory.createSocket(port, backlog, inet);
+}
+if (serverTimeout = 0)
+serverSocket.setSoTimeout(serverTimeout);
+} catch (Throwable t) {
+
mod_status and mod_info returns wrong version of mod_jk2-1.3-eapi.so(2.0.1)
Hi folks, currently I'm busy on tomcat and mod_jk2 (2.0.1) for my new employer. The Apache Server Status and Information page thinks that mod_jk2/2.0.0 is loaded. But I'm sure that mod_jk2-1.3-eapi.so is version 2.0.1. That's it ... greetings from Germany Volker -- We haven't figured out how to be lower priced than Linux. Steve Ballmer (Microsoft) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13781] New: - Non-existent file name given to jsp:include does not generate FNE
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=13781. 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=13781 Non-existent file name given to jsp:include does not generate FNE Summary: Non-existent file name given to jsp:include does not generate FNE Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A non-existent file given as value to the page attribute of the jsp:include standard action does not generate java.io.FileNotFoundException. I tested the same in Tomcat 4.0.2, it properly generates FNE -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Suggestion for Admin Console
I really like the new administration web app for Tomcat. I think it will go a long way to further the use of Tomcat by users that want to focus on building their application and not have to learn the configuration XML structures of Tomcat. I also think this type of an Administration Console application could have many other applications as well. This could be the container console for configuration tools for Apache, Tomcat, Jetspeed, your home-grown app goes here. Has there been any consideration to making this console application it's own Jakarta project and modifying it to support Administration Plugins?
AW: Bug 13736
Bill, Remy, I have seen this one once on our production system running Tomcat 3.3.1 with AJP1.3, Apache 1.3.27, mod_jk 1.1.0 This is on Sparc Solaris 8 running JDK 1.3.1_04. 11019 is our ajp13 port (which we uswe also as shutdown port. No AJP 1.2 port open) Our webservers use the lb_worker to connect to the Tomcat servers (different machine) It occured, when we had a bug in our application causing an endless stacktrace, which filled up our logs.( 5000 !!! MB per minute). At some stage, the JVM crashed out after a stack overflow. Before the crash, tomcat got slower and slower due to the massive logging. 11019 is our ajp13 port (which we uswe also as shutdown port. No AJP 1.2 port open) I can reproduce the endless stacktrace, but am not sure to get the ServerSocket error (can not reproduce this on our production server for obvious reasons) PoolTcpEndpoint: Endpoint ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=11019] ignored exception: java.net.SocketException: Interrupted system call java.net.SocketException: Interrupted system call at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:463) at java.net.ServerSocket.implAccept(ServerSocket.java:238) at java.net.ServerSocket.accept(ServerSocket.java:217) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultSe rverSocketFactory.java:107) at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java :326) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:472) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:516) at java.lang.Thread.run(Thread.java:479) 2002-10-05 16:01:24 - Ctx(/einsurance) : IllegalStateException in R( /einsurance + /view + /screens/car/carDescription.htm) - java.lang.IllegalStateException: Cannot forward because the response has already been committed at org.apache.tomcat.facade.RequestDispatcherImpl.doForward(RequestDispatcherIm pl.java:207) at org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl .java:174) at de.einsurance.gui.framework.ExceptionHandler.handle(ExceptionHandler.java:25 5) at de.einsurance.gui.framework.ExceptionHandler.handle(ExceptionHandler.java:15 1) at de.einsurance.gui.framework.ExtendedActionServlet.process(ExtendedActionServ let.java:69) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:491) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485) at org.apache.tomcat.facade.RequestDispatcherImpl.doForward(RequestDispatcherIm pl.java:272) at org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl .java:174) at org.apache.struts.action.ActionServlet.processActionForward(ActionServlet.ja va:1758) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595) at de.einsurance.gui.framework.ExtendedActionServlet.process(ExtendedActionServ let.java:65) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:491) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:91 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Ajp13Interceptor.processConnection(Ajp13Int erceptor.java:341) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:516) at java.lang.Thread.run(Thread.java:479) Cheers, Hans -Ursprungliche Nachricht- Von: Remy Maucherat [mailto:remm;apache.org] Gesendet: Freitag, 18. Oktober 2002 20:15 An: Tomcat Developers List Betreff: Re: Bug 13736 Bill Barker wrote: +1. As I said above, it probably hasn't shown up in 3.3 mostly because AJP13 has many fewer accepts. I'll fix it then. You have to be careful that no IOException should end up in that code, otherwise, for each one the server socket will be restarted (not good). With
DO NOT REPLY [Bug 13784] New: - Missing Javadoc documentation
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=13784. 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=13784 Missing Javadoc documentation Summary: Missing Javadoc documentation Product: Tomcat 4 Version: 4.1.12 Platform: All URL: http://jakarta.apache.org/tomcat/tomcat-4.1- doc/catalina/docs/api/index.html OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Webapps:Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The Web site and the release distribution are missing the javadoc documentation for 4.1. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
