Re: Addition of 'dirty' field to Session interface
It seams that we all think in a similar way. We can have a solution like this: We have an instance of the database to store the sessions. The table for the session can be something like this: sessionId, sessionVersion, sessionLocker, extraSessionData, sessionStream sessionId : a unique id for session [yes the id ;-)] sessionVersion : an identifier which say when it was modified for the last time (not a timestamp but a number) sessionLocker : who is locking the session (an id for the virtual machine) extraSessionData : some data like when it should experire (on dbtime) or well, I dont know. sessionStream : the serialized session (so all the object stored in the session should implement serializable). Session creation is a litle tricky because be should get sure that no other virtual machine is trying to create the same session (for the same user) and if so syncronize them. On every request: - get the lock sessionLocker (check if the locker is 0, if it is we take it; if it is not we wait until the locker is 0 try again). [sessionLocker = me] - check if it is the same sessionVersion. - if yes just use the session at memory. (why unserilize it if we can have them in memory?). - if not get the session of the database (sessionStream) and unserialize it. * now the user request runs as normal, until it is finished when .. - sessionVersion++ - sessionStream gets updated. - sessionLocker = 0 There are other optimizations but I will not discuss them now not to make a mess. The problems I see are most of all user problems like not making the objects serializable or making a bad use of the singleton pattern (we are running on multiple machines), or some dirty finalize methods. Ok, there will we some overhead but it will be after the http stream was flushed. An there is nothing like a free meal. (Yes, it should only get activated if the user dessires so) ((user=apache admin). Does apache has a mean of doing load balancing? If so, can we make it sticky so we optimize resources? Chau, Gaston - Original Message - From: "Reilly, John" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 24, 2001 8:51 PM Subject: RE: Addition of 'dirty' field to Session interface > > > > > This is just an idea from the top of my head, would > > > it be possible > > > having a second vector that contains a footprint(not > > > a full clone) of > > > the > > > object for a session and have a reaper thread > > > checking the footprints > > > against > > > the "real" objects and determine if they changed or > > > not and based on > > > that > > > replicate of whatever we want to do. > > > > My thoughts exactly. If you want to be able to > > support transparent fail-over for sessions within a > > cluster, you are going to have to take the performance > > hit of persisting the session data on at least 1 other > > machine in the cluster after every request. If you're > > already taking that step, you might as well maintain > > an in-memory image of the serialized session object. > > You could compare an MD5 on the bytes comprising the > > session before the request was handled with the MD5 > > for after the request completed. > > > > Could this work? > > The overhead could be fairly signifigant. > > > > > - osama.
RuntimeException handling in WebApp initialization
Hi, I noticed when a Filter (probably pre-loaded Servlets too) throws RuntimeException it's logged, but not displayed, and then it makes an WebApp entirely unavailable (503 error). While not display an error summarizing exception name, message, optionally stack trace in stdout? Normally (Tomcat running as a deamon) stdout is ignored, but if such info would be displayed it would speed up error tracing in development environment. Looks like it could be easily fixed by a small addition between lines 3000-3100 in StandardContext, at least for filters. Something like displaying: Starting Tomcat... [...] Exception while initializing Filter for context "hostname": Exception name: RuntimeException Exception msg: error reading xml configuration from file "/WEB-INF/filter-config.xml" WebApp "hostname" unavailable because of errors in Listeners initializers. I'd say stack trace isn't necessary here because it's availabe in logs, and writing in would probably scroll exception name and message off-screen (not all environments have scrolling on command line) which would defeat its purpose on making this info available instantly. Greetings, deacon Marcus p.s. I'm using Tomcat 4.0 b6
cvs commit: jakarta-tomcat/src/etc modules.xml
larryi 01/08/26 19:13:42 Modified:src/etc modules.xml Log: Removed mappings for classes which no longer exist. Removed PoolTcpConnector since it can't be used directly. Its localInit() method is abstract. Revision ChangesPath 1.12 +0 -16 jakarta-tomcat/src/etc/modules.xml Index: modules.xml === RCS file: /home/cvs/jakarta-tomcat/src/etc/modules.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- modules.xml 2001/08/16 00:35:40 1.11 +++ modules.xml 2001/08/27 02:13:42 1.12 @@ -1,14 +1,10 @@ - - - - @@ -17,12 +13,6 @@ - - - - - - @@ -43,15 +33,9 @@ - - - - - -
cvs commit: jakarta-tomcat/src/doc serverxml.html
larryi 01/08/26 19:19:10
Modified:src/doc serverxml.html
Log:
Added alphabetical list of standard modules, plus a bit of rearranging
and miscellaneous editing.
Revision ChangesPath
1.2 +575 -218 jakarta-tomcat/src/doc/serverxml.html
Index: serverxml.html
===
RCS file: /home/cvs/jakarta-tomcat/src/doc/serverxml.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- serverxml.html2001/08/21 05:58:36 1.1
+++ serverxml.html2001/08/27 02:19:10 1.2
@@ -3,32 +3,45 @@
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd";>
http://www.w3.org/1999/xhtml";>
+
+
+
Server.xml configuration in tomcat 3.3
-
-
+
+
+
+
+ http://jakarta.apache.org/index.html";>
+
+
+
+
General configuration
Tomcat is implemented using a set of modules. Each module has a
-number of settable properties and implements one or few 'hooks', implementing a
+number of settable properties and implements one or more 'hooks', providing a
piece of functionality.
The modules can be configured and assembled in sevaral ways, but the
default and most flexible mechanism uses XML files. Each module is described
by an XML element, with attributes used to set module properties. The main
-configuration file is located in TOMCAT_HOME/conf/server.xml, used to
-configure the server. Additional TOMCAT_HOME/conf/server-[NAME].xml files
-will be read after server.xml, allowing local configurations.
+configuration file is located in TOMCAT_HOME/conf/server.xml, used to
+configure the server. Additional
TOMCAT_HOME/conf/server-name.xml files
+will be read after server.xml, allowing local configurations.
Variable substitution
-Each attribute value may use ant-style variable substitution ( ${variable}
+Each attribute value may use the ant-style variable substitution ( ${variable}
). The values are stored as ContextManager properties, and defined using
-either element, or in the command line using "-foo bar"
syntax, or as system properties.
@@ -37,23 +50,18 @@
All modules have the following common attributes:
-
-
- Attribute
-
- Description
-
- Default
-
-
-
- debug
-
- Display debug information on the module execution
-
- 0
-
-
+
+Attribute
+Description
+Default
+
+
+debug
+
+Display debug information on the module execution
+
+0
+
Configuration Elements
@@ -63,6 +71,12 @@
javadoc will contain most details, in this document we focus on the common
and supported behaviors.
+Parent Configuration Elements
+
+The purpose of the server.xml is to define the configuration of an instance
+of the Tomcat 3.3 web server. The parent configuration elements in the
+server.xml file represent that instance.
+
Server
@@ -83,125 +97,149 @@
Description
-Main tag, used to set generic tomcat options. It has few types of
-childrens:
+This is the main tag, used to set generic Tomcat options. The following are
+some of the childen it supports:
- <[MODULE_NAME]>
-Define a module. Module names are defined in module.xml, where each tag is
- associated with a class name that implements the module. Each element
- attribute coresponds to a setter method in the implementing class
+
+Adds a module to the configuration. Module names are defined in
+ module.xml, where each tag is associated with a class name that
+ implements the module. Each element attribute coresponds to a setter
+ method in the implementing class.
-Defines a web application. As a rule, applications should be defined
-in separate config files, named apps-[NAME].xml
-
+Defines a web application. This is a legacy method of specifying a
+ web application. It is included for backward compatibility with older
+ Tomcats. As a rule, applications should be defined in separate config
+ files, named apps-name.xml. This way you can configure your
+ web applications without modifying your server.xml file.
+
Adds arbitrary name/values to ContextManager. The properties can be
- used for variable substitutions, or instead of attributes.
-
-Define a module. All modules included in the standard distrib
Re: Tomcat 3.2.3 and getPathInfo
> > > This is even worse because we also won't allow the URL to be > > encoded like > > > > > > http://localhost:8080/servlet/SnoopServlet/http:%2F%2Ffubar > > > > > > because we make some rather draconian precautions to ensure that nastily > > > encoded URLs can't obtain access to protected resources (or > > even resources > > > outside the webapp). > > > > Hmm... I wonder if Tomcat has the right to make illegal what HTTP would > > allow? > > As I recall, our constraints were basically lifted from the Apache HTTP > server. Our rationale was that it was far better to preclude some odd URLs > than to leave open the possibility that files outside the web application > could be accessed via the container. This was a *really* bad security hole. So what does the Apache Web Server do for PATH_INFO on a request to http://foo.com/cgi-bin/somecgi/http://extra.com? -jh-
Re: Tomcat 3.2.3 and getPathInfo
On Sun, Aug 26, 2001 at 10:24:30PM -0700, Jason Hunter wrote: > So what does the Apache Web Server do for PATH_INFO on a request to > http://foo.com/cgi-bin/somecgi/http://extra.com? Ask for /index.html/http://extra.com with httpd-2.0, it strips out the second /. (gdb) print r->path_info $5 = 0x813debc "/http:/extra.com" HTH. -- justin
