cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContext.java
kief01/04/15 02:27:56
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
Removed code to save sessions on restart or shutdown: this should
be done in the Manager stop method.
Revision ChangesPath
1.52 +4 -20
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -r1.51 -r1.52
--- StandardContext.java 2001/04/09 06:52:10 1.51
+++ StandardContext.java 2001/04/15 09:27:56 1.52
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.51 2001/04/09 06:52:10 remm Exp $
- * $Revision: 1.51 $
- * $Date: 2001/04/09 06:52:10 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.52 2001/04/15 09:27:56 kief Exp $
+ * $Revision: 1.52 $
+ * $Date: 2001/04/15 09:27:56 $
*
*
*
@@ -141,7 +141,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.51 $ $Date: 2001/04/09 06:52:10 $
+ * @version $Revision: 1.52 $ $Date: 2001/04/15 09:27:56 $
*/
public class StandardContext
@@ -2281,13 +2281,6 @@
ContextBindings.unbindThread(this, this);
}
-// Unload sessions to persistent storage, if supported
-try {
-getManager().unload();
-} catch (Throwable t) {
-log(sm.getString("standardContext.managerUnload"), t);
-}
-
// Shut down filters and application event listeners
filterStop();
listenerStop();
@@ -3313,15 +3306,6 @@
// Mark this application as unavailable while we shut down
setAvailable(false);
-
-// Unload sessions to persistent storage, if supported
-try {
-if (debug = 1)
-log("Saving persisted sessions");
-getManager().unload();
-} catch (Throwable t) {
-log(sm.getString("standardContext.managerUnload"), t);
-}
// Stop our filters and application listeners
filterStop();
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session PersistentManagerBase.java PersistentManager.java
kief01/04/15 02:33:27
Modified:catalina/src/share/org/apache/catalina/session
PersistentManager.java
Added: catalina/src/share/org/apache/catalina/session
PersistentManagerBase.java
Log:
Refactored PersistentManager, moving basic persistence functionality,
as well as Lifecycle and background maintenance threat, into
PersistentManagerBase. This base class can also be used for
StandardManager's session reloading feature, once it has been tested
thoroughly.
These classes will undoubtedly go through some significant revisions,
especially once we start working on DistributedManager.
Revision ChangesPath
1.7 +110 -620
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java
Index: PersistentManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- PersistentManager.java2001/04/12 20:24:36 1.6
+++ PersistentManager.java2001/04/15 09:33:27 1.7
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
1.6 2001/04/12 20:24:36 kief Exp $
- * $Revision: 1.6 $
- * $Date: 2001/04/12 20:24:36 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
1.7 2001/04/15 09:33:27 kief Exp $
+ * $Revision: 1.7 $
+ * $Date: 2001/04/15 09:33:27 $
*
*
*
@@ -106,12 +106,12 @@
* liLimit the number of active sessions kept in memory by
* swapping less active sessions out to disk./li
*
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
* @author Kief Morris ([EMAIL PROTECTED])
*/
public final class PersistentManager
-extends ManagerBase
+extends PersistentManagerBase
implements Lifecycle, PropertyChangeListener, Runnable {
@@ -119,54 +119,12 @@
/**
- * The interval (in seconds) between checks for expired sessions.
- */
-private int checkInterval = 60;
-
-
-/**
* The descriptive information about this implementation.
*/
private static final String info = "PersistentManager/1.0";
/**
- * The lifecycle event support for this component.
- */
-protected LifecycleSupport lifecycle = new LifecycleSupport(this);
-
-
-/**
- * The maximum number of active Sessions allowed, or -1 for no limit.
- */
-private int maxActiveSessions = -1;
-
-
-/**
- * Has this component been started yet?
- */
-private boolean started = false;
-
-
-/**
- * The background thread.
- */
-private Thread thread = null;
-
-
-/**
- * The background thread completion semaphore.
- */
-private boolean threadDone = false;
-
-
-/**
- * Name to register for the background thread.
- */
-private String threadName = "PersistentManager";
-
-
-/**
* Whether to save and reload sessions when the Manager codeunload/code
* and codeload/code methods are called.
*/
@@ -174,7 +132,7 @@
/**
- * How long a session must be idle before it is backed up.
+ * How long a session must be idle before it should be backed up.
* -1 means sessions won't be backed up.
*/
private int maxIdleBackup = -1;
@@ -194,91 +152,11 @@
*/
private int maxIdleSwap = -1;
-/**
- * Store object which will manage the Session store.
- */
-private Store store = null;
-
// - Properties
/**
- * Return the check interval (in seconds) for this Manager.
- */
-public int getCheckInterval() {
-
-return (this.checkInterval);
-
-}
-
-
-/**
- * Set the check interval (in seconds) for this Manager.
- *
- * @param checkInterval The new check interval
- */
-public void setCheckInterval(int checkInterval) {
-
-int oldCheckInterval = this.checkInterval;
-this.checkInterval = checkInterval;
-support.firePropertyChange("checkInterval",
- new Integer(oldCheckInterval),
- new Integer(this.checkInterval));
-
-}
-
-
-/**
- * Set the Container with which this Manager has been associated. If
- * it is a Context (the usual case), listen for changes to the session
- * timeout property.
- *
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionIdGenerator.java
Doug Barnes wrote: The answer to these arguments are: use /dev/urandom, not /dev/random. It's going to do as good or better than anything you're going to seed with /dev/random, and IT WILL NOT BLOCK. I may be wrong (I'm just starting to poke around in related code) but it doesn't look like the time and the session counter values you're appending to create the SessionID have any subsequent meaning. If you're looking for more entropy, I'd ditch the time and use another long's worth of /dev/urandom. I'm aware of /dev/urandom being non-blocking, but my understanding of /dev/urandom is that it is not cryptographicaly secure. From the Linux random manual page (man 4 random): When read, /dev/urandom device will return as many bytes as are requested. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theo retically vulnerable to a cryptographic attack on the algorithms used by the driver. Any thoughts on that? Bojan
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContext.java LocalStrings.properties
kief01/04/15 03:45:28
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java LocalStrings.properties
Log:
Removed code to load sessions on start or restart - this code has
been moved to the Manager start method.
Revision ChangesPath
1.53 +4 -25
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- StandardContext.java 2001/04/15 09:27:56 1.52
+++ StandardContext.java 2001/04/15 10:45:28 1.53
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.52 2001/04/15 09:27:56 kief Exp $
- * $Revision: 1.52 $
- * $Date: 2001/04/15 09:27:56 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.53 2001/04/15 10:45:28 kief Exp $
+ * $Revision: 1.53 $
+ * $Date: 2001/04/15 10:45:28 $
*
*
*
@@ -141,7 +141,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.52 $ $Date: 2001/04/15 09:27:56 $
+ * @version $Revision: 1.53 $ $Date: 2001/04/15 10:45:28 $
*/
public class StandardContext
@@ -2350,15 +2350,6 @@
}
}
-// Load sessions from persistent storage, if supported
-try {
-if (ok)
-getManager().load();
-} catch (Throwable t) {
-log(sm.getString("standardContext.managerLoad"), t);
-ok = false;
-}
-
if (isUseNaming()) {
try {
ContextBindings.bindThread(this, this);
@@ -3209,18 +3200,6 @@
if (debug = 1)
log("Posting standard context attributes");
postWelcomeFiles();
-}
-
-// Reload sessions from persistent storage if supported
-try {
-if (ok) {
-if (debug = 1)
-log("Loading persisted sessions");
-getManager().load();
-}
-} catch (Throwable t) {
-log(sm.getString("standardContext.managerLoad"), t);
-ok = false;
}
// Collect "load on startup" servlets that need to be initialized
1.30 +368 -186
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/LocalStrings.properties,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- LocalStrings.properties 2001/04/10 01:37:08 1.29
+++ LocalStrings.properties 2001/04/15 10:45:28 1.30
@@ -1,186 +1,368 @@
-applicationContext.attributeEvent=Exception thrown by attributes event listener
-applicationContext.requestDispatcher.iae=Path {0} does not start with a "/"
character
-applicationDispatcher.allocateException=Allocate exception for servlet {0}
-applicationDispatcher.deallocateException=Deallocate exception for servlet {0}
-applicationDispatcher.forward.ise=Cannot forward after response has been committed
-applicationDispatcher.forward.throw=Forwarded resource threw an exception
-applicationDispatcher.include.throw=Included resource threw an exception
-applicationDispatcher.isUnavailable=Servlet {0} is currently unavailable
-applicationDispatcher.serviceException=Servlet.service() for servlet {0} threw
exception
-applicationRequest.badParent=Cannot locate parent Request implementation
-applicationRequest.badRequest=Request is not a javax.servlet.ServletRequestWrapper
-applicationResponse.badParent=Cannot locate parent Response implementation
-applicationResponse.badResponse=Response is not a
javax.servlet.ServletResponseWrapper
-containerBase.addDefaultMapper=Exception configuring default mapper of class {0}
-containerBase.alreadyStarted=Container {0} has already been started
-containerBase.notConfigured=No basic Valve has been configured
-containerBase.notStarted=Container {0} has not been started
-filterChain.filter=Filter execution threw an exception
-filterChain.servlet=Servlet execution threw an exception
-httpContextMapper.container=This container is not a StandardContext
-httpEngineMapper.container=This container is not a StandardEngine
-httpHostMapper.container=This container is not a StandardHost
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session StandardManager.java
kief01/04/15 03:48:55
Modified:catalina/src/share/org/apache/catalina/session
StandardManager.java
Log:
Moved session loading/unloading to the start/stop methods from
StandardContext. Also commented out the requirement that the
session serialization file path be absolute.
Revision ChangesPath
1.8 +20 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardManager.java
Index: StandardManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardManager.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- StandardManager.java 2001/04/12 18:18:57 1.7
+++ StandardManager.java 2001/04/15 10:48:55 1.8
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardManager.java,v
1.7 2001/04/12 18:18:57 kief Exp $
- * $Revision: 1.7 $
- * $Date: 2001/04/12 18:18:57 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardManager.java,v
1.8 2001/04/15 10:48:55 kief Exp $
+ * $Revision: 1.8 $
+ * $Date: 2001/04/15 10:48:55 $
*
*
*
@@ -105,7 +105,7 @@
* codestop()/code methods of this class at the correct times.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.7 $ $Date: 2001/04/12 18:18:57 $
+ * @version $Revision: 1.8 $ $Date: 2001/04/15 10:48:55 $
*/
public class StandardManager
@@ -583,6 +583,13 @@
if (debug = 1)
log("Force random number initialization completed");
+// Load unloaded sessions, if any
+try {
+load();
+} catch (Throwable t) {
+log(sm.getString("standardManager.managerLoad"), t);
+}
+
// Start the background reaper thread
threadStart();
@@ -613,6 +620,13 @@
// Stop the background reaper thread
threadStop();
+// Write out sessions
+try {
+unload();
+} catch (IOException e) {
+log(sm.getString("standardManager.managerUnload"), e);
+}
+
// Expire all active sessions
Session sessions[] = findSessions();
for (int i = 0; i sessions.length; i++) {
@@ -679,8 +693,8 @@
file = new File(tempdir, pathname);
}
}
-if (!file.isAbsolute())
-return (null);
+//if (!file.isAbsolute())
+//return (null);
return (file);
}
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session LocalStrings.properties
kief01/04/15 03:50:04
Modified:catalina/src/share/org/apache/catalina/session
LocalStrings.properties
Log:
Moved error messages for loading/unloading sessions from core (StandardContext)
to here (StandardManager).
Revision ChangesPath
1.6 +2 -0
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/LocalStrings.properties,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- LocalStrings.properties 2001/04/10 13:01:55 1.5
+++ LocalStrings.properties 2001/04/15 10:50:04 1.6
@@ -17,6 +17,8 @@
standardManager.notStarted=Manager has not yet been started
standardManager.sessionTimeout=Invalid session timeout setting {0}
standardManager.unloading=Saving persisted sessions to {0}
+standardManager.managerLoad=Exception loading sessions from persistent storage
+standardManager.managerUnload=Exception unloading sessions to persistent storage
standardSession.attributeEvent=Session attribute event listener threw exception
standardSession.invalidate.ise=invalidate: Session already invalidated
standardSession.isNew.ise=isNew: Session already invalidated
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionIdGenerator.java
I'm aware of /dev/urandom being non-blocking, but my understanding of /dev/urandom is that it is not cryptographicaly secure. ... Any thoughts on that? [perhaps more thoughts than anyone here cares to hear, but what the heck] You only have so much entropy that's available on a given machine at a given time. From the same manpage, you can see that if you have access to more entropy than /dev/random knows about normally, you can write it back to /dev/random (they give an example) but at the end of the day, you need to decide -- is it more important that the SessionIDs be safe from an opponent with vast computational and/or intercept capabilities, or is it more important to not block. My guess is that in the vast majority of cases it's more important to not block. /dev/urandom is going to do as good of a job of stretching the available entropy as any other computationally reasonable approach that you could implement. My summary of the criticism of /dev/urandom is that it might not be a hot idea to use it to generate a long-lived private/public key pair, but I can't see how you can do any better if you need a long, reliable stream of randomness (e.g. a whole bunch of hard-to-predict SessionIDs.) Here's this from the source code of linux/drivers/char/random.c: * When random bytes are desired, they are obtained by taking the SHA * hash of the contents of the "entropy pool". The SHA hash avoids * exposing the internal state of the entropy pool. It is believed to * be computationally infeasible to derive any useful information * about the input of SHA from its output. Even if it is possible to * analyze SHA in some clever way, as long as the amount of data * returned from the generator is less than the inherent entropy in * the pool, the output data is totally unpredictable. For this * reason, the routine decreases its internal estimate of how many * bits of "true randomness" are contained in the entropy pool as it * outputs random numbers. * * If this estimate goes to zero, the routine can still generate * random numbers; however, an attacker may (at least in theory) be * able to infer the future output of the generator from prior * outputs. This requires successful cryptanalysis of SHA, which is * not believed to be feasible, but there is a remote possibility. * Nonetheless, these numbers should be useful for the vast majority * of purposes. Let's think about how someone might attack a weakness in a SessionID generator. Assume that the victim computer's version of Linux has a bug that causes /dev/urandom to be seeded with all zeroes every time it boots, and that it never adds any entropy. If the opponent guessed or knew that this was the case, then the opponent could connect to the webserver, get a SessionID, and would then be able to make very good guesses about what other SessionIDs were currently in use. (By starting from all zeroes, and applying the algorithm until the obtained SessionID was reached.) Assuming that some sort of "entropy" is being added, the next thing the attacker could do is to come up with a way to either predict what is being added as "entropy", or at least guess at it with substantially more effectiveness than random chance. One early version of this many years ago was when Ian Goldberg and Dave Wagner discovered that an early version of Netscape's web server was seeding their random number generator with nothing more than the time and the PID, both of which were sufficiently easy to guess at that it was quite easy to predict what session keys would be generated. However, unless the attacker has successfully cryptanalyzed SHA (which would have far greater consequences than the ability to predict SessionIDs in Tomact :-) the attacker is going to have to successfully model ALL entropy ever added in. After the first eighty or so bits of "real entropy," it's going to be easier to just guess random SessionIDs (with some cleverness about predicting the time and the session counter, which are both predictable and inter-related) Note that the chance of guessing _a_ session (as opposed to a particular session) goes up steadily with the total number of valid sessions. (Let's say, for the sake of example, that you have a 1/2^80 chance of guessing a particular session; if you have 2048 valid sessions, it improves to a 1/2^69 chance.) For this reason, if you're really paranoid, you'll want to increase the part of the SessionID from /dev/urandom to 128 bits and ditch the use of the time (unless it has semantic value down the food chain that I'm missing.) This way, as long as you have more than 128 bits of "real entropy", it's going to be "easier" for the attacker to make the on average num_sessions/2^127 guesses needed to find a valid SessionID. Hope this is helpful! Cheers, Doug
RE: mod_webapp, mod_jk etc.
mod_jk should be compiled statically in Apache but nobody asked for that feature previously since mod_jk as still not the maturity of other well known modules like mod_index. A feature which may be added to mod_jk, but I'd like to see before autoconf stuff added :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 10, 2001 10:32 AM To: [EMAIL PROTECTED] Subject: Re: mod_webapp, mod_jk etc. Forgot to ask, would you be interested in instructions/simple shell script for building mod_jk as a statically linked Apache module? Bojan Dan Milstein wrote: I can't speak to mod_webapp, but a mod_jk response: - I understand the need for the TCP connections to be persistent in mod_jk and mod_webapp, but I'm not sure why another connection wouldn't be attempted after the reuse of the previous connection fails; This was just added to the 3.3 branch (by Henri) for mod_jk -- if the Apache plugin detects a dead connection, it opens a new one (so you don't have to restart Apache when you restart Tomcat). Needs testing, but it's in there. -Dan -- Dan Milstein // [EMAIL PROTECTED]
RE: mod_webapp help!
I didn't have much more luck with gcc on my Redhat 6.2 system.
mod_webapp in the distro is just incomplete. It was compiling
on previous release 4.0b1 but no more with recent.
Wait for Pier to fix it
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: T. Park [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 11, 2001 6:24 PM
To: [EMAIL PROTECTED]
Subject: mod_webapp help!
Hi Folks,
Can anyone advise me how to build it using the sources supplied with
tomcat 4.0 b3?
My end goal is to be able to build it on NT with MSVC 6.0, but
I've been
trying to get it to
compile on Solaris 2.8 with the 6.1 C compiler.
I know that it was written for gcc - my next step is to try to
use gcc -
I was hoping to avoid having to employ gcc as it's use will cause me
some 'productization' headaches)
I'm trying to findout what WA_LOG should be - it's referred to in
several places but there is not definition of it in the
makefiles or the
C code.
Also, some of the code constructs appear to be C++ rather than C - was
this intentional?
e.g.
struct wa_connection {}
where wa_connection is subsequently used as a datatype.
In 'strict' C it would be more proper to write something like:
typedef struct wa_connection wa_connection_t;
struct wa_connection {...}
and use wa_connection_t as the datatype.
If I feed the former to a 'strict' C compiler - it's not a
happy camper.
Note: I'm not trying to be picky here - this just came to light when I
tried to use Microsoft C and Solaris C on the sources,
as there were no binaries available for the platforms that I'm using.
I guess my next step is to try with gcc on Solaris and then on windows
- with some porting work ;-)
Again - is there anyone doing the Win NT work at the moment? If not I'm
more than happy to volunteer.
-Thom
--
http://www.borland.com/newsgroups
http://www.borland.com/devsupport/disclaim.html
RE: Bug 1006 not fixed in 3.2.2b3
The fix was just for the native HTTP connector and didn't cover ajp12/ajp13. We could certainly add the same type of code in ajp12 but with a more little timeout (30 seconds) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, April 13, 2001 10:47 PM To: Marc Saegesser Cc: [EMAIL PROTECTED] Subject: RE: Bug 1006 not fixed in 3.2.2b3 I am using ajp12 with 3.2.2b3 and I am still experiencing this problem. It appears that ajp12 makes a back-end connection per http request "Marc Saegesser" [EMAIL PROTECTED] on 04/12/2001 07:23:00 PM To: Tom Harding/WPAC/GSAG_Corp@GSAG_Corp cc: Subject RE: Bug 1006 not fixed in 3.2.2b3 : Tom, It really is fixed. What happened was the right after I made the change to PoolTcpEndpoint.java it was pointed out to me that the correct place to make the change is in HttpConnectionHandler.java. The PoolTcpEndpoint class gets used by other protocols (like ajp13) that have persistent connections that shouldn't time out for inactivity. I just tested Tomcat 3.2.2b3 and the timeout appears to be working. Just use telnet to connection to Tomcat and after 5 minutes of inactivity the connection is closed. I'm pretty sure Henri made the same fix to 3.3, but I don't have the code in front of me to verify that. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 12, 2001 2:48 PM To: [EMAIL PROTECTED] Subject: Bug 1006 not fixed in 3.2.2b3 Mark, In bug 1006 you say that you fixed the non-timeout of sockets "Fixed in 3.2.2b2. I'm leaving this open so that it can be also be fixed in 3.3 and later" However in the PoolTcpEndpoint.java source from 3.2.2b3, which starts like this.. * * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/Attic /PoolTcpEndpoint.java,v 1.8.2.5 2001/03/21 17:11:29 marcsaeg Exp $ * $Revision: 1.8.2.5 $ * $Date: 2001/03/21 17:11:29 $ I don't see any setting of socket options per the fix mentioned in the bug. Also I'm still having the symptoms of the problem. Is the fix really included in 3.2.2b3? Thanks, Tom Harding
RE: Bug 1006 not fixed in 3.2.2b3
I took a quick look before and thought I saw timeout handling already in the ajp handler. -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 15, 2001 6:38 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Bug 1006 not fixed in 3.2.2b3 The fix was just for the native HTTP connector and didn't cover ajp12/ajp13. We could certainly add the same type of code in ajp12 but with a more little timeout (30 seconds) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, April 13, 2001 10:47 PM To: Marc Saegesser Cc: [EMAIL PROTECTED] Subject: RE: Bug 1006 not fixed in 3.2.2b3 I am using ajp12 with 3.2.2b3 and I am still experiencing this problem. It appears that ajp12 makes a back-end connection per http request "Marc Saegesser" [EMAIL PROTECTED] on 04/12/2001 07:23:00 PM To: Tom Harding/WPAC/GSAG_Corp@GSAG_Corp cc: Subject RE: Bug 1006 not fixed in 3.2.2b3 : Tom, It really is fixed. What happened was the right after I made the change to PoolTcpEndpoint.java it was pointed out to me that the correct place to make the change is in HttpConnectionHandler.java. The PoolTcpEndpoint class gets used by other protocols (like ajp13) that have persistent connections that shouldn't time out for inactivity. I just tested Tomcat 3.2.2b3 and the timeout appears to be working. Just use telnet to connection to Tomcat and after 5 minutes of inactivity the connection is closed. I'm pretty sure Henri made the same fix to 3.3, but I don't have the code in front of me to verify that. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 12, 2001 2:48 PM To: [EMAIL PROTECTED] Subject: Bug 1006 not fixed in 3.2.2b3 Mark, In bug 1006 you say that you fixed the non-timeout of sockets "Fixed in 3.2.2b2. I'm leaving this open so that it can be also be fixed in 3.3 and later" However in the PoolTcpEndpoint.java source from 3.2.2b3, which starts like this.. * * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/Attic /PoolTcpEndpoint.java,v 1.8.2.5 2001/03/21 17:11:29 marcsaeg Exp $ * $Revision: 1.8.2.5 $ * $Date: 2001/03/21 17:11:29 $ I don't see any setting of socket options per the fix mentioned in the bug. Also I'm still having the symptoms of the problem. Is the fix really included in 3.2.2b3? Thanks, Tom Harding
