Re: New tag ?
On 7/23/05, Mark Thomas [EMAIL PROTECTED] wrote: I have been doing some quick tests and my totally unscientific, statistically invalid results are that cvs annotate seems to be about 7 to 8 times faster than svn blame (50s compared with 7s) and cvs log seems to be about 2 to 3 times faster than svn log (16s compared to 7s). I've heard the subversion developers remind people that there are at least a few different network protocols for accessing svn. In the http:// case, it will be the slowest. IIRC they say using the svn:// protocol is the fastest. It looks as if the Apache svn installation does not support svn:// URLs. The page that shows the URLs doesn't mention it: http://jakarta.apache.org/site/cvsindex.html#Subversion And when I try to connect to the svn port (tcp 3690) I get a connection refused. So, maybe the infrastructure people could set up a svnserve server as well as serving these repositories through Apache httpd? http://svnbook.red-bean.com/en/1.1/ch06s03.html I use svn and I'm looking forward to having Tomcat hosted in it. Remy: isn't svn blame what you're looking for? -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat build fails: junit
Jonathan Maasland wrote: Hi Marco, First off, this is the dev-list so I don't think this is the right place for your question. Use tomcat-user for these types of questions. He sent this to the dev list because he's building it (more of a developer thing to do), as opposed to just using the release binary. He's passing on the info that one of the build properties no longer works so that the Tomcat committers can fix that for themselves and for other developers. This is the appropriate mailing list for that, not tomcat-user. -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] - benchmark on APR stuff
Peter Rossbach wrote: Hey Peter, I have download and install Jmeter 2.0.3 and want load your testplans, but I got this error: 2005/05/03 06:45:43 INFO - jmeter.gui.action.Load: Loading file: D:\peterlintestplan\concurrent_1.jmx 2005/05/03 06:45:43 ERROR - jmeter.save.SaveService: Problem loading part of file org.apache.avalon.framework.configuration.ConfigurationException: No attribute named class is associated with the configuration element testelement at - [snip] What I made wrong? Apparently JMeter 2.0.3 is too old. :) I downloaded and built JMeter from CVS head, and that allowed me to load and run his test plans. Cheers. -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs cluster-howto.xml
[EMAIL PROTECTED] wrote: pero2005/04/29 13:14:58 Modified:webapps/docs cluster-howto.xml Log: Not ready, but add some important information about current cluster modul implementation details. Revision ChangesPath 1.6 +428 -7jakarta-tomcat-catalina/webapps/docs/cluster-howto.xml [snip] section name=FAQ pTo be completed once I receive questions about session replication:/p ol -liQ: What happens when I pull the network cord?p/p +liQ: What happens when I pull the network card?p/p Actually, I think this really is supposed to be cord, not card. Maybe replacing it with the word cable would be better? Cheers. -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5.9 runs on Kaffe 1.1.5 (was Re: Tomcat and APR)
Jason Brittain wrote: Remy Maucherat wrote: Jason Brittain wrote: This release of Apache Tomcat was packaged to run on J2SE 5.0 or later. It can be run on earlier JVMs by downloading and installing a compatibility package from the Apache Tomcat binary download page. means JMX wasn't found, that's all. Okay, I confirmed at least one way to make Tomcat 5.5.9 run on Kaffe 1.1.5. Adding the jmx.jar to the Kaffe's boot classpath works: # export CATALINA_BASE=/home/$USER/jakarta-tomcat-5.5.9 # export CATALINA_OPTS=-Xbootclasspath/p:$CATALINA_BASE/bin/jmx.jar # cd $CATALINA_BASE # bin/catalina.sh start Now, Tomcat runs. I tried the JSP examples, and they work. I'll see about benchmarking it versus JDK 1.4.x and 1.5.x. :) Thanks for the help Remy. -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.9 runs on Kaffe 1.1.5 (was Re: Tomcat and APR)
Remy Maucherat wrote: Jason Brittain wrote: Jason Brittain wrote: Now, Tomcat runs. I tried the JSP examples, and they work. I'll see about benchmarking it versus JDK 1.4.x and 1.5.x. :) It's really bad. APR might help a little. Surprisingly, it looked reasonable when I benchmarked it today. Here are the results: Kaffe 1.1.5 250 users -- 205/sec throughput, 3.3 average, 0% error 500 users -- 307/sec throughput, 11.4 average, 0% error 1000 users -- 325/sec throughput, 370.7 average, 0% error 2000 users -- 138/sec throughput, 3048.8 average, 0% error JDK 1.5.0 250 users -- 204/sec throughput, 2.8 average, 0% error 500 users -- 307/sec throughput, 42.2 average, 0% error 1000 users -- 390/sec throughput, 124.1 average, 0% error 2000 users -- 294/sec throughput, 130.8 average, 0% error When the concurrency was high, Kaffe was quite a bit slower. But, at the low end, it seems to keep up with Sun JDK 1.5.0 just fine. I did see some problems though: several webapps I tried didn't work due to random misc JVM problems in Kaffe. It's still looking a bit incompletely implemented. For the above test, I used jmeter CVS HEAD with Peter Lin's concurrent1 test plan (from http://cvs.apache.org/~woolfel/native_testplans.zip), modified for my box's IP address, and to request /tomcat.gif. The tested box is a Fedora Core 2 x86 32 box (running Tocmat 5.5.9). The tester box is a Fedora Core 3 x86 32 box (running jmeter). Remy: Maybe the slowness you saw with kaffe is on win32? -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Remy Maucherat wrote: This has been hinted for a while ;) The purpose of this email is to propose using APR (Apache Portable Runtime) as the network IO used by Tomcat, instead of the JVM's IO. [snip] Which will allow: [snip] - (likely) better performance and reliability on free JVMs This sounds as though you're implying that Tomcat already runs on one or more free JVM. Which ones? And, any particular version? All of them that I have tried can't run Tomcat. Before, it was just that they each used the GNU Classpath core classes, which were (still are?) too incomplete, and even though the required classes were found and loaded, they were either incomplete (missing some methods for instance), or they were wrong somehow and caused random fatal startup problems. Most of the problems seemed to have to do with either reflection or JMX or both. Here's how my last attempt went (SableVM Version 1.1.10): [EMAIL PROTECTED] jakarta-tomcat-5.5.8-with-compat]# java-sablevm -Djava.endorsed.dirs=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/common/endorsed -classpath :/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/bin/bootstrap.jar:/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/bin/commons-logging-api.jar -Dcatalina.base=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat -Dcatalina.home=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat -Djava.io.tmpdir=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/temp org.apache.catalina.startup.Bootstrap start Created MBeanServer with ID: [UID: 8594076,1109751203829,-32768]:localhost.localdomain:1 java.lang.IllegalArgumentException: argument of incorrect type at java.lang.reflect.Method.invoke (Method.java:461) at org.apache.catalina.startup.Bootstrap.setAwait (Bootstrap.java:337) at org.apache.catalina.startup.Bootstrap.main (Bootstrap.java:407) at java.lang.VirtualMachine.invokeMain (VirtualMachine.java) at java.lang.VirtualMachine.main (VirtualMachine.java:108) So, I'm still looking for even one free/OSS JVM that is capable of running Tomcat. -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Remy Maucherat wrote: Jason Brittain wrote: Remy Maucherat wrote: This has been hinted for a while ;) The purpose of this email is to propose using APR (Apache Portable Runtime) as the network IO used by Tomcat, instead of the JVM's IO. [snip] Which will allow: [snip] - (likely) better performance and reliability on free JVMs This sounds as though you're implying that Tomcat already runs on one or more free JVM. Which ones? And, any particular version? gij-4.0 (so gcjing portions should work), I haven't tried this one yet. It'll require some time to set up properly. kaffe 1.1.5, Nope: [EMAIL PROTECTED] jakarta-tomcat-5.5.9]# bin/catalina.sh start Using CATALINA_BASE: /home/jbrittain/jakarta-tomcat-5.5.9 Using CATALINA_HOME: /home/jbrittain/jakarta-tomcat-5.5.9 Using CATALINA_TMPDIR: /home/jbrittain/jakarta-tomcat-5.5.9/temp Using JRE_HOME: /usr/local/kaffe [EMAIL PROTECTED] jakarta-tomcat-5.5.9]# cd logs [EMAIL PROTECTED] logs]# more catalina.out WARNING: System property java.util.logging.manager should be the name of a subclass of java.util.logging.LogManager This release of Apache Tomcat was packaged to run on J2SE 5.0 or later. It can be run on earlier JVMs by downloading and installing a compatibility package from the Apache Tomcat binary download page. [EMAIL PROTECTED] logs]# java -version Kaffe Virtual Machine Copyright (c) 1996-2004 Kaffe.org project contributors (please see the source code for a full list of contributors). All rights reserved. Portions Copyright (c) 1996-2002 Transvirtual Technologies, Inc. The Kaffe virtual machine is free software, licensed under the terms of the GNU General Public License. Kaffe.org is a an independent, free software community project, not directly affiliated with Transvirtual Technologies, Inc. Kaffe is a Trademark of Transvirtual Technologies, Inc. Kaffe comes with ABSOLUTELY NO WARRANTY. Engine: Just-in-time v3 Version: 1.1.5 Java Version: 1.1 ... And, this is *with* Tomcat's compat package installed properly. This may just be a bug in Tomcat's J2SE 5.0 detection code (bad expectations w.r.t. free JVMs?). Or, maybe kaffe just doesn't implement what we know we need? Either way, it doesn't work. probably others. I wish I knew. None have worked so far for me. [snip] Well, if you try the only VM which doesn't work ;) No, like I said, I tried several brands versions. -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Remy Maucherat wrote: Jason Brittain wrote: Nope: [EMAIL PROTECTED] jakarta-tomcat-5.5.9]# bin/catalina.sh start Using CATALINA_BASE: /home/jbrittain/jakarta-tomcat-5.5.9 Using CATALINA_HOME: /home/jbrittain/jakarta-tomcat-5.5.9 Using CATALINA_TMPDIR: /home/jbrittain/jakarta-tomcat-5.5.9/temp Using JRE_HOME: /usr/local/kaffe [EMAIL PROTECTED] jakarta-tomcat-5.5.9]# cd logs [EMAIL PROTECTED] logs]# more catalina.out WARNING: System property java.util.logging.manager should be the name of a subclass of java.util.logging.LogManager If for some reason the java.util.logging impl isn't compatible with classpath, remove it (delete tomcat-juli.jar). Okay. I did that, and tried it again. Now it doesn't give that warning, but Tomcat still fails to run in the same way. For the rest, install the compat package. You must not have read the paragraph in my last email that said: ... And, this is *with* Tomcat's compat package installed properly. -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Remy Maucherat wrote: Jason Brittain wrote: You must not have read the paragraph in my last email that said: ... And, this is *with* Tomcat's compat package installed properly. Maybe there's a regression. It used to work long before 1.1.5 anyway, I'm curious to know which version of Tomcat ran like that. I've tried more than a few versions. but it could be that the classpath generation using the manifest from JARs doesn't work (it does in gij, where you can do a -jar bin/boostrap.jar). So add jmx.jar and tomcat-juli.jar to the classpath to fix it. Just so you know, I unjarred bootstrap.jar (from 5.5.9) and here's what the manifest looks like: [EMAIL PROTECTED] bootstrap]# cat META-INF/MANIFEST.MF Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.2 Created-By: 1.4.2_06-b03 (Sun Microsystems Inc.) Main-Class: org.apache.catalina.startup.Bootstrap Specification-Title: Catalina Specification-Version: 1.0 Class-Path: jmx.jar commons-daemon.jar commons-logging-api.jar tomcat- juli.jar Notice the tomcat-\r juli.jar in there! This release of Apache Tomcat was packaged to run on J2SE 5.0 or later. It can be run on earlier JVMs by downloading and installing a compatibility package from the Apache Tomcat binary download page. means JMX wasn't found, that's all. Yes. I did: [EMAIL PROTECTED] jakarta-tomcat-5.5.9]# export CLASSPATH=/home/jbrittain/jakarta-tomcat-5.5.9/bin/jmx.jar and then started it again, and it still didn't find JMX (same message in catalina.out). If that's what you meant, it didn't work. -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Remy Maucherat wrote: Jason Brittain wrote: This release of Apache Tomcat was packaged to run on J2SE 5.0 or later. It can be run on earlier JVMs by downloading and installing a compatibility package from the Apache Tomcat binary download page. means JMX wasn't found, that's all. Yes. I did: [EMAIL PROTECTED] jakarta-tomcat-5.5.9]# export CLASSPATH=/home/jbrittain/jakarta-tomcat-5.5.9/bin/jmx.jar and then started it again, and it still didn't find JMX (same message in catalina.out). If that's what you meant, it didn't work. CLASSPATH is obviously ignored. This has been like that for years. At first I thought that was the case, so I had a brief look in 5.5.9's catalina.sh script and found this: # Add on extra jar files to CLASSPATH if [ -n $JSSE_HOME ]; then CLASSPATH=$CLASSPATH:$JSSE_HOME/lib/jcert.jar:$JSSE_HOME/lib/jnet.jar:$JSSE_HOME/lib/jsse.jar fi CLASSPATH=$CLASSPATH:$CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/commons-logging-api.jar ... which is used farther down like: $_RUNJAVA $JAVA_OPTS $CATALINA_OPTS \ -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS -classpath $CLASSPATH \ ... It must not have the effect on the JVM that I thought it may. So then to what classpath should I add jmx.jar? -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
subsection name=Cluster changelog add +DeltaManager has now JMX expireAllLocalSessions and processExipre operation +for better cluster node shutdown handling (pero) + /add Why would we want to invalidate all sessions active on one node of the cluster when bringing it down, as opposed to replicating the session data out to one or more other available nodes in the cluster and letting the other machine(s) handle them? Or, did you add these operations/methods for cases where the cluster is configured to keep any given session on exactly one node? (I wouldn't think so, since in that case what would the session clustering really be useful for?) Just curious.. -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: In memory session replication, reminder
GOMEZ Henri wrote: You can start with my doc, there are two references to JavaGroups in there http://www.filip.net/tomcat/tomcat-javagroups.html http://www.javagroups.com/ - Does it use multicast or others broadcast techniques ? Virtual Synchrony and Probabilistic broadcasting on top of IP Multicasting. see the docs Excellent stuff, something which could have its room in jakarta !!! JavaGroups is cool since it is pure, multiplatform Java, although (from what I know) it cannot fall back to TCP when multicast isn't available, and the license could be better.. :) If you liked that, also have a look at Spread: http://www.spread.org/ The messaging engine (daemon) isn't written in Java, but it's very fast and efficient, and runs on all the popular OSs. The Java clients connect to it via TCP sockets, so the clients can be pure-Java. The License is similar to the Apache license, and unlike JavaGroups the engine does know to fall back to using TCP unicast when multicast is not available. It's been around for quite some time, too. What I'd like to do at some point is take Filip Hanik's TC4 session replication code (looking nice!) and make it switchable to use either Spread or JavaGroups, or other communication mechanisms for keeping the session data in sync. Pluggable messaging back-ends.. FWIW, I'd like to see the in-memory session replication code as part of TC4 itself, with a pluggable messaging layer API that allows a separate messaging system to be used. But, if people decide that it's better suited to j-t-c, then that's okay (not quite as good, IMO), but I'd still like it to have a pluggable messaging layer API. Cheers. -- Jason Brittain [EMAIL PROTECTED] 650-228-2644 CollabNet http://www.collab.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.0.3] [VOTES] Upcoming release and security fix
Hi Remy and gang.. Below is my non-binding vote (for fun!): Remy Maucherat wrote: Since there are apparently diverging opinions on the subject (and also since I didn't get any +1s for a possible 4.0.3 b1, or a 4.0.2a release), here's a formal request for vote. On the security problem reported yesterday, affecting the security manager sandboxing. We should: ballot A [X] Make a full 4.0.3 (or 4.0.2a) release which would only include the security fix This looks to me to be the path of least resistance/hassle for everyone involved, since it's just a small change to the last release. Release early, release often. :) B [ ] Make the security fix available as a binary patch for 4.0.2 (it would take the form of an archive to extract in $CATALINA_HOME, and would be *small*) Binary patches make me nervous. Whether this would work best or not depends on a whole bunch of unspecified factors, so I won't vote for it. C [ ] Accelerate the release schedule of 4.0.3, which would include the security fix, as well as fixes for other issues with 4.0.2 (with Beta 1 on 03/01 and Final on 03/08) /ballot This one would be nice too, but it creates a bunch of extra work for you it seems (which is my guess as to why you're not voting for it). Multiple votes are acceptable. If there are other interesting possibilities, let me know. My vote is 'B'. In parallel, I'd like to release a first beta of 4.0.3 on 03/01 (depending on the vote on item 'C' above, the release cycle may be shorter or longer): ballot +1 [ ] I support the release, and I will help +0 [X] I support the release, and I sure wish I had time to help!! -0 [ ] I don't support the release -1 [ ] I'm against the release because: -- Jason Brittain jasonb (at) collab (dot) net CollabNet http://www.collab.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves AccessLogValve.java
Remy Maucherat wrote: Since the bug was likely originally my fault, I felt compelled to report to you about this missing hunk. :) I didn't backport this since I didn't think it was useful. It should just save a few operations if there's a race there, I think. Maybe it would be safer to add it too. Remy Yeah, I was thinking it would be a good idea for consistency (future patching across more than one branch, etc.). Thanks for fixing it.. -- Jason Brittain jasonb(at)collab(dot)net CollabNet http://www.collab.net
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves AccessLogValve.java
Hi Remy!
Cool bugfix, but you forgot to backport a piece of it:
@@ -604,11 +612,14 @@
// If the date has changed, switch log files
if (!dateStamp.equals(tsDate)) {
synchronized (this) {
-close();
-dateStamp = tsDate;
-open();
+if (!dateStamp.equals(tsDate)) {
+close();
+dateStamp = tsDate;
+open();
+}
}
}
+
}
// Log this message
Since the bug was likely originally my fault, I felt compelled to
report to you about this missing hunk. :)
Keep up the excellent work!
--
Jason Brittain
jasonb(at)collab(dot)net
CollabNet http://www.collab.net
[EMAIL PROTECTED] wrote:
remm01/10/23 16:08:10
Modified:catalina/src/share/org/apache/catalina/valves Tag:
tomcat_40_branch AccessLogValve.java
Log:
- Port fix for 4327.
Revision ChangesPath
No revision
No revision
1.10.2.1 +10 -2
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java
Index: AccessLogValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java,v
retrieving revision 1.10
retrieving revision 1.10.2.1
diff -u -r1.10 -r1.10.2.1
--- AccessLogValve.java 2001/08/27 19:10:26 1.10
+++ AccessLogValve.java 2001/10/23 23:08:10 1.10.2.1
@@ -128,7 +128,7 @@
*
* @author Craig R. McClanahan
* @author Jason Brittain
- * @version $Revision: 1.10 $ $Date: 2001/08/27 19:10:26 $
+ * @version $Revision: 1.10.2.1 $ $Date: 2001/10/23 23:08:10 $
*/
public final class AccessLogValve
@@ -300,6 +300,12 @@
private boolean resolveHosts = false;
+/**
+ * Instant when the log daily rotation was last checked.
+ */
+private long rotationLastChecked = 0L;
+
+
// - Properties
@@ -594,9 +600,11 @@
// Only do a logfile switch check once a second, max.
long systime = System.currentTimeMillis();
-if ((systime - currentDate.getTime()) 1000) {
+if ((systime - rotationLastChecked) 1000) {
+
// We need a new currentDate
currentDate = new Date(systime);
+rotationLastChecked = systime;
// Check for a change of date
String tsDate = dateFormatter.format(currentDate);
You Can't Say WebApp! -- was cvs commit: jakarta-tomcat-4.0/service/java ServiceController.java
[EMAIL PROTECTED] wrote: pier01/06/25 18:32:07 Added: service/java ServiceController.java Log: Full UNIX service implementation checkin [snip] * 4. The names The Jakarta Project, WebApp, and Apache Software * *Foundation must not be used to endorse or promote products derived * *from this software without prior written permission. For written * *permission, please contact [EMAIL PROTECTED]. * I fully realize the intent of the above clause in the license for mod_webapp, but I have to ask.. The term web application and web app have been used for years, especially with the word server on the end, it's become a generic but descriptive label that is today widely used in all kinds of documentation for commercial products and open source projects. Even though you've removed the space between the two words web and app, to me it doesn't really change the term significantly. Am I alone here? What the license above is saying is that noone can take Tomcat 4 (with mod_webapp and its pure-Java-side connector), modify some part of the source, and use the term WebApp to endorse or promote their project or product. So, are you and/or the Apache Software Foundation now claiming exclusive rights to the use of the name WebApp as this license clause claims? -- Jason Brittain [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: FW: [advanced-servlets] Session Load Balancing (was: To avoid
Nick Bauman wrote: Jason, Yes, and the way I've seen people solve this issue is to make each server constantly replicate its sessions to another server so that any session's state is stored in two servers (not just one). For example, if you've got four servers, A, B, C, and D, you configure A to replicate to B, B to replicate to C, C to replicate to D, and D to replicate to A. Then the "composite ID" would contain the primary server tag, secondary server tag, and the session ID, like: A:B:sessionXXX. So, if server A went down, the load balancer could still get session info from server B, and at the same time let server D know that A is down and to replicate to B until further notice. Nh. This is once again only making sure a majority of the sessions are saved in a rotation. A lot of work for very little real fault tolerance. Sorry to say, but the folks at BEA disagree with you -- this is exactly what Weblogic does to facilitate distributed HTTP sessions. In-memory replication to a selected "buddy" server is pretty fast and fault tolerant enough for most failures. It can also ensure no single point of failure. Also I think your english up there indicates a solution that causes tremendous hysterysis amongst the servers. How so? This also works when each server replicates sessions to more than one backup server so that you've got even higher fault tolerance (but you'll probably never need that level of fault tolerance). Now you may have something: a seperate, parallel, session cluster. Anyone could sure do it that way. But, I'm not sure that separating it out from the servers themselves could add much fault tolerance since the cons to doing this seem to be about as large as the pros. It seems to me that making it part of the servers (the servlet containers, for instance) would work just as well. -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FW: [advanced-servlets] Session Load Balancing (was: To avoid
Nick Bauman wrote: Pier, If the next request from that client is routed to server Y, then server Y will get a request with that same composite ID of "serverX:sessionPPP". This tells server Y that the first thing it needs to do is get the canonical version of Session sessionPPP from server X. (The exact method for this may vary, but suffice to say it will not involve spawning Threads from Servlets. :-) In the response The only problem with this is you have N servers in a rotation (sprayed or DNS round-robin) and one goes down, you lose 1/N sessions. Some people think that if you are going to bother with session load balancing / distribution at all, why not try and ensure all the sessions are safe, not just a majority. Yes, and the way I've seen people solve this issue is to make each server constantly replicate its sessions to another server so that any session's state is stored in two servers (not just one). For example, if you've got four servers, A, B, C, and D, you configure A to replicate to B, B to replicate to C, C to replicate to D, and D to replicate to A. Then the "composite ID" would contain the primary server tag, secondary server tag, and the session ID, like: A:B:sessionXXX. So, if server A went down, the load balancer could still get session info from server B, and at the same time let server D know that A is down and to replicate to B until further notice. This also works when each server replicates sessions to more than one backup server so that you've got even higher fault tolerance (but you'll probably never need that level of fault tolerance). -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup CatalinaBlock.java CatalinaBlock.xinfo
Pier P. Fumagalli wrote: Remy Maucherat [EMAIL PROTECTED] wrote: Quoting Jason Brittain [EMAIL PROTECTED]: Please let me know when you're ready to discuss my TomcatBlock patches.. No hurry on my part, I just want to keep the idea warm. :) Feel free to see it in action at: http://eas.betaversion.org I just went there by accident this morning. Stop stealing the bandwidth I'm using for my email (which is [EMAIL PROTECTED]) ;) We'll reintroduce the wrapper when the 4.1 repository is recreated, which should happen just after TC 4 beta 2. Actually, eas.betaversion.org is not at my place, Remy, only your email is. EAS.BETAVERSION.ORG is Jason's machine, I just aliased the DNS (unless someone didn't put it on there without me knowing it :) Pier Nope, it's on my machine. Thanks for letting us hitchhike on your domain, Pier! It works great.. betaversion.org is cool! :) -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] CatalinaBlock.java
Sam Ruby wrote: Jason van Zyl wrote: While playing with Sam Ruby's gump I noticed that the CatalinaBlock is out of sync with Avalon. Not sure if staying right up-to-date is critical but here's the patch anyway. Until Avalon ships, tracking to the current APIs is the only way to go. I've committed the changes. Thanks! - Sam Ruby If you like that patch, you'll probably also like the ones I sent in on Friday -- messages with the title "[PATCH] TC4: TomcatBlock on Avalon 3.1a1".. Cheers. ===== Jason Brittain [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] TC4: TomcatBlock on Avalon 3.1a1: Part 1
Hi guys. I've just finished a bunch of changes to make Tomcat 4 (Catalina and Jasper) work on top of Avalon 3.1a1. Remy: Thanks for CatalinaBlock -- it served as a good starting point! What I've done is made the necessary modifications to make Tomcat 4 build as a single Avalon .bar (Block ARchive) file that when deployed into Avalon auto-deploys its own files and directories from the bar file to the filesystem where Catalina and Jasper can use them. Some of my goals that are now done: 1) Make Tomcat 4 deployable as a single .bar file. 2) Make Catalina log through Avalon's LogKit package. 3) Make Jasper work so that JSPs also work (this was tough as it turned out). 4) Make Tomcat's build system able to build the .bar file. 5) Only patch Catalina's code where absolutely necessary, and then only make patches that are sure not to disturb stand-alone behavior. In the process, I decided that the name of the block should really be TomcatBlock, not CatalinaBlock, since the block contains Catalina, Jasper, and the demo/test webapps. Let me know if you don't agree. So, I've replaced CatalinaBlock with TomcatBlock, which is based on CatalinaBlock but is heavily modified. In order to make Catalina log through Avalon, I rewrote the AccessLogValve so that we now have FileAccessLogValve and AvalonAccessLogValve which are both subclasses of AccessLogValveBase. I also added org.apache.catalina.logger.AvalonFileLogger so that the other logs can also log through Avalon. I modified the main build.xml file and also Catalina's build.xml file so that from the top-level you can do: ./build.sh dist then ./build.sh dist-opt-avalon in order to build tomcat-4.0.bar. I moved that target out of Catalina's build.xml file because it needs to include more than just Catalina. So now it resides in the top-level build.xml file, and its behavior is quite a bit different. At first, Catalina ran fine this way, but Jasper didn't. I narrowed the problem down to the fact that Jasper needs tools.jar on its classpath, and that it wasn't finding it. In order to fix the problem, I had to make a small patch to the Bootstrap class. I'll go into more detail about that in one of my next mails (including the diff). What changed overall? Files removed: catalina/src/conf/catalina.conf.xml catalina/src/share/org/apache/catalina/valves/AccessLogValve.java catalina/src/share/org/apache/catalina/startup/CatalinaBlock.java catalina/src/share/org/apache/catalina/startup/CatalinaBlock.xinfo Files patched: build.xml catalina/build.xml catalina/src/share/org/apache/catalina/core/ContainerBase.java catalina/src/share/org/apache/catalina/startup/Bootstrap.java Files added: catalina/src/conf/avalon-MANIFEST.MF catalina/src/conf/avalon-server.xml catalina/src/conf/tomcat-4.0.conf.xml catalina/src/share/org/apache/catalina/logger/AvalonFileLogger.java catalina/src/share/org/apache/catalina/startup/TomcatBlock.java catalina/src/share/org/apache/catalina/startup/TomcatBlock.xinfo catalina/src/share/org/apache/catalina/valves/AccessLogValveBase.java catalina/src/share/org/apache/catalina/valves/AvalonAccessLogValve.java catalina/src/share/org/apache/catalina/valves/FileAccessLogValve.java After all of these changes I made, Tomcat 4 still builds and runs stand-alone the same as it did before (as far as I can tell by my somewhat limited testing) and it runs as an Avalon 3.1a1 Block. I know this is a bunch of new code, but I think I've tested and documented it enough to make it clear and easy commit. My next mails will include the diffs and the new source. -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] TC4: TomcatBlock on Avalon 3.1a1: Part 2
Attached are the diffs to the files that I modified to make TomcatBlock (Tomcat 4 running on Avalon 3.1a1). Explanation: build.xml (the top-level build.xml file) I moved the dist-opt-avalon target (and associated stuff) to this file since to build the bar file it needs to copy stuff from Catalina, Jasper, and webapps. catalina/build.xml Removed the dist-opt-avalon target from this file, added some more lines about only compiling Avalon-dependent source if Avalon is present. catalina/src/share/org/apache/catalina/core/ContainerBase.java I needed to fix an obscure bug in this file to get AvalonFileLogger to work. What was happening was: When one of the class loaders starts up, it tries to log some things in some cases. But, its logger has not yet been started yet, so the class loader ends up throwing an exception (can't remember what kind). To fix this, I switched the startup order: the loader's logger gets started first, then the loader that uses it gets started. I'm not real sure how this could have worked properly before this patch. :) catalina/src/share/org/apache/catalina/startup/Bootstrap.java This one's the tough one! I had a hard time getting Jasper to work inside the TomcatBlock, even after the block deployed all of the usual directories to the filesystem. This is because Jasper needs the JDK's tools.jar on its classpath. When you run Catalina from the command line (stand-alone), the startup script catalina.sh puts tools.jar on the classpath: if [ -f "$JAVA_HOME/lib/tools.jar" ] ; then CP=$CP:"$JAVA_HOME/lib/tools.jar" fi But, when starting from Avalon, you don't have the shell script to add it to the classpath for you. So, I figured all I needed to do was have TomcatBlock create its own ClassLoader that adds tools.jar (and maybe some other jars too) and start up the Bootstrap class just like CatalinaBlock did, but load it from the ClassLoader that TomcatBlock created. So, I tried that. It didn't work. After tearing out some hair, I found the problem. Bootstrap's createCommonLoader() method creates a new StandardClassLoader with a set of URLs (an array of them) like this: StandardClassLoader loader = new StandardClassLoader(array); This constructor of StandardClassLoader makes a new StandardClassLoader with the array of URLs (to jars or other paths) setting the default parent class loader as its parent, instead of setting Bootstrap's ClassLoader as its parent. This caused Jasper to not use the class loader I created to give it access to tools.jar, thus making Jasper not work. Now, if there is some good reason to deliberately not make Bootstrap's classloader the parent class loader of the common class loader, then my patch needs to be reworked. But, I couldn't think of any reasons. And, I could think of reasons why you would want to make Bootstrap's class loader the parent of the common class loader.. In the classloader.html doc, it says that the "Common" class loader's parent is supposed to be the "System" class loader (that is to say, the class loader created from the contents of CLASSPATH at runtime). When you run Tomcat stand-alone, this is indeed what happens. I guess the "System" class loader is the "default" parent, so it works. But, when TomcatBlock created its own class loader, that new class loader is not the default, so it's never the parent of the "Common" class loader, so there is no way of adding tools.jar (or other jars) to the Common class loader's search path. I suppose this is only a problem when you're trying to start up Catalina using Bootstrap the way we need to in order to make the Avalon Block. Someone else suggested that I use EmbeddedTomcat instead, but from what I understand that means that I also must implement my own config system, which I don't really want to do. :) So, what my patch to Bootstrap does: it uses Bootstrap's own class loader as the parent of the Common class loader. And, when you run in stand-alone mode, this is (conveniently) the System class loader. My next mail shows the files I added. -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] TC4: TomcatBlock on Avalon 3.1a1: Part 2 (for real this time)
Last time I forgot to attach the diffs! Sorry.. This mail has them.
Attached are the diffs to the files that I modified to make TomcatBlock
(Tomcat 4 running on Avalon 3.1a1).
Explanation:
build.xml (the top-level build.xml file)
I moved the dist-opt-avalon target (and associated stuff) to this file
since to build the bar file it needs to copy stuff from Catalina,
Jasper, and webapps.
catalina/build.xml
Removed the dist-opt-avalon target from this file, added some more
lines about only compiling Avalon-dependent source if Avalon is
present.
catalina/src/share/org/apache/catalina/core/ContainerBase.java
I needed to fix an obscure bug in this file to get AvalonFileLogger to
work. What was happening was: When one of the class loaders starts
up, it tries to log some things in some cases. But, its logger has
not yet been started yet, so the class loader ends up throwing an
exception (can't remember what kind). To fix this, I switched the
startup order: the loader's logger gets started first, then the loader
that uses it gets started. I'm not real sure how this could have
worked properly before this patch. :)
catalina/src/share/org/apache/catalina/startup/Bootstrap.java
This one's the tough one!
I had a hard time getting Jasper to work inside the TomcatBlock, even
after the block deployed all of the usual directories to the
filesystem. This is because Jasper needs the JDK's tools.jar on its
classpath. When you run Catalina from the command line (stand-alone),
the startup script catalina.sh puts tools.jar on the classpath:
if [ -f "$JAVA_HOME/lib/tools.jar" ] ; then
CP=$CP:"$JAVA_HOME/lib/tools.jar"
fi
But, when starting from Avalon, you don't have the shell script to add
it to the classpath for you. So, I figured all I needed to do was
have TomcatBlock create its own ClassLoader that adds tools.jar (and
maybe some other jars too) and start up the Bootstrap class just like
CatalinaBlock did, but load it from the ClassLoader that TomcatBlock
created.
So, I tried that. It didn't work. After tearing out some hair, I
found the problem. Bootstrap's createCommonLoader() method creates a
new StandardClassLoader with a set of URLs (an array of them) like
this:
StandardClassLoader loader = new StandardClassLoader(array);
This constructor of StandardClassLoader makes a new
StandardClassLoader with the array of URLs (to jars or other paths)
setting the default parent class loader as its parent, instead of
setting Bootstrap's ClassLoader as its parent. This caused Jasper to
not use the class loader I created to give it access to tools.jar,
thus making Jasper not work.
Now, if there is some good reason to deliberately not make Bootstrap's
classloader the parent class loader of the common class loader, then
my patch needs to be reworked. But, I couldn't think of any reasons.
And, I could think of reasons why you would want to make Bootstrap's
class loader the parent of the common class loader..
In the classloader.html doc, it says that the "Common" class loader's
parent is supposed to be the "System" class loader (that is to say,
the class loader created from the contents of CLASSPATH at runtime).
When you run Tomcat stand-alone, this is indeed what happens. I guess
the "System" class loader is the "default" parent, so it works. But,
when TomcatBlock created its own class loader, that new class loader
is not the default, so it's never the parent of the "Common" class
loader, so there is no way of adding tools.jar (or other jars) to the
Common class loader's search path. I suppose this is only a problem
when you're trying to start up Catalina using Bootstrap the way we
need to in order to make the Avalon Block.
Someone else suggested that I use EmbeddedTomcat instead, but from
what I understand that means that I also must implement my own config
system, which I don't really want to do. :)
So, what my patch to Bootstrap does: it uses Bootstrap's own class
loader as the parent of the Common class loader. And, when you run
in stand-alone mode, this is (conveniently) the System class loader.
My next mail shows the files I added.
--
Jason Brittain
Software Engineer, Olliance Inc.http://www.Olliance.com
Current Maintainer, Locomotive Project http://www.Locomotive.org
--- build.xml Fri Feb 9 14:53:03 2001
+++ build.xml-new Fri Feb 9 12:00:40 2001
@@ -8,11 +8,13 @@
property name="tomcat.dist" value="${basedir}/dist"/
property name="webapps.build" value="${basedir}/webapps/build"/
property name="webapps.dist"value="${basedir}/webapps/dist"/
-
property name="catalina.deploy" value="${tomcat.build}"/
property name="jasper.deploy" value="${tomcat.build}"/
property name="webapps.deploy" value="${tomcat.build}"/
-
+ property name=
[PATCH] TC4: TomcatBlock on Avalon 3.1a1: Part 3
Attached are the files I added to make TomcatBlock (Tomcat 4 running on Avalon 3.1a1): catalina/src/conf/avalon-MANIFEST.MF This manifest file is used to create tomcat-4.0.bar. Avalon needs a special manifest to know which Block is contained in the BAR file. catalina/src/conf/avalon-server.xml When Tomcat runs on Avalon, it needs a special/tailored server.xml. This is it. It's not really that different from the regular server.xml file, so we may want to make the build system just apply a diff (?) instead of copying this whole file in as "server.xml" like I've set it up to do currently.. catalina/src/conf/tomcat-4.0.conf.xml This is one of the config files that tells Avalon about the Tomcat bar file. catalina/src/share/org/apache/catalina/logger/AvalonFileLogger.java Allows Catalina to log through Avalon. catalina/src/share/org/apache/catalina/startup/TomcatBlock.java The main Block class that makes it all happen. catalina/src/share/org/apache/catalina/startup/TomcatBlock.xinfo An Avalon Block descriptor file for TomcatBlock. catalina/src/share/org/apache/catalina/valves/AccessLogValveBase.java The superclass of both FileAccessLogValve and AvalonAccessLogValve. catalina/src/share/org/apache/catalina/valves/AvalonAccessLogValve.java This is an AccessLogValve that sends the web server access log through Avalon's logging system. catalina/src/share/org/apache/catalina/valves/FileAccessLogValve.java This is the stand-alone AccessLogValve that simply writes the output to a file on the filesystem. This class replaces the older, now obsolete AccessLogValve class. And that's it. Let me know what you think.. :) -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org Manifest-Version: 1.0 Created-By: Apache Avalon Project Name: org/apache/catalina/startup/TomcatBlock.class Avalon-Block: true !-- This is an example server configuration file for Tomcat running on -- !-- top of the Avalon server framework. Note: these settings won't -- !-- work when you run Tomcat without Avalon!-- !-- Note that component elements are nested corresponding to their parent-child relationships with each other -- !-- A "Server" is a singleton element that represents the entire JVM, which may contain one or more "Service" instances. The Server listens for a shutdown command on the indicated port. Note: A "Server" is not itself a "Container", so you may not define subcomponents such as "Valves" or "Loggers" at this level. -- Server port="8005" shutdown="SHUTDOWN" debug="0" !-- A "Service" is a collection of one or more "Connectors" that share a single "Container" (and therefore the web applications visible within that Container). Normally, that Container is an "Engine", but this is not required. Note: A "Service" is not itself a "Container", so you may not define subcomponents such as "Valves" or "Loggers" at this level. -- !-- Define the Tomcat Stand-Alone Service -- Service name="Tomcat-Standalone" !-- A "Connector" represents an endpoint by which requests are received and responses are returned. Each Connector passes requests on to the associated "Container" (normally an Engine) for processing. By default, a non-SSL HTTP/1.1 Connector is established on port 8080. You can also enable an SSL HTTP/1.1 Connector on port 8443 by following the instructions below and uncommenting the second Connector entry. SSL support requires the following steps: * Download and install JSSE 1.0.2 or later, and put the JAR files into "$JAVA_HOME/jre/lib/ext". * Edit "$JAVA_HOME/jre/lib/security/java.security" and add security.provider.2=com.sun.net.ssl.internal.ssl.Provider * Execute: keytool -genkey -alias tomcat -keyalg RSA with a password value of "changeit". -- !-- Define a non-SSL HTTP/1.1 Connector on port 8080 -- Connector className="org.apache.catalina.connector.http.HttpConnector" port="8080" minProcessors="5" maxProcessors="75" acceptCount="10" debug="0" connectionTimeout="6"/ !-- Note : To disable connection timeouts, set connectionTimeout value to -1 -- !-- Define an SSL HTTP/1.1 Connector on port 8443 -- !-- Connector className="org.apache.catalina.connector.http.HttpConnector" port="8443" minProcessors="5" maxProcessors="75" acceptCount="10&
Re: [PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades
Remy Maucherat wrote: Quoting "Craig R. McClanahan" [EMAIL PROTECTED]: org.apache.catalina.facade.XFacade Nice package name. I wonder where you got it :) :) Unless I understand wrong, isn't a "facade" already a well known feature that allows Tomcat 3.x to use more than one different version of the Servlet API? Am I wrong and it does more than just that? If I'm right, that means you're proposing to use the name "facade" in the Tomcat 4 codebase to have a completely different meaning, right? If this is the case, could we instead use a different name? I'm not sure what name I would use.. "sandbox" maybe? -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AccessLogValve Patch
In the message I just wrote: --- AccessLogValve.java Wed Jan 10 15:16:10 2001 +++ AccessLogValve.java-new Wed Jan 10 15:15:50 2001 @@ -61,6 +61,7 @@ package org.apache.catalina.valves; +import java.io.BufferedWriter; import java.io.File; import java.io.FileWriter; import java.io.IOException; Oops! I forgot to remove the BufferedWriter import before I made the patch.. Please remove that line. Thanks! -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat session replicator
cky Sessions.. what if you use it with two other algorithms and they override the Sticky Session and send the request elsewhere where it doesn't have its session replicated?). So, there should be two main types of load balancing algorithms: Democratic algorithms, and Dictator algorithms. Dictator algorithms don't vote on where to send the request, they just send it. Democratic algorithms work together, voting about where to send a request, and each algorithm's vote is weighted. Regardless of the load balancing algorithm(s) used, the request will never be redirected to a server that is down. For this to work, the load balancer must be able to maintain contact with each content server. This contact should be configurable as well. Possible choices may include: - TCP Socket Keepalive: each redirect server opens a single TCP socket connection to each content server (to something like an echo service) and keeps the connection alive by sending data to the content server to be echoed back to the redirect server. If the TCP connection breaks and cannot be reestablished, the redirect server considers that content server to be unavailable and will not send any requests to it again until the TCP connection can be reestablished. - UDP Ping: each redirect server periodically sends a UDP message out to a content server (the content server implements a UDP echo service) to be echoed back to the redirect server. If packets are lost for longer than a configurable timeout interval, then the redirect server considers that content server to be down until it begins echoing back the UDP ping messages. Comments? Suggestions? -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org
Re: Benchmarks: Catalina M5 vs. Apache 1.3.12
Hi there Chris. You can certainly do just what I did, use ApacheBench and see what numbers you get with each server. There's also another tester called Apache JMeter, which will show you graphical views of the tests as they're happening. JMeter has some bugs, but it's good anyway. You can find it here: http://java.apache.org/jmeter/index.html Try that out too. And, it would be great if you could share your results, even if you don't go into the depth about your tests as I did.. Have fun! -- Jason Curtis Dougherty wrote: Jason - I am attempting to generate some server performance numbers as well. What tool would you recommend to test TOMCAT vs. WebLogic JRun et al.??? If you can point me in the right direction for a good test harness to plug-in I would be very grateful. Thank you for your time and consideration of this matter. Regards, Curtis QA Engineer BusinessThreads -Original Message- From: Jason Brittain [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 05, 2000 12:48 PM To: [EMAIL PROTECTED] Subject: Benchmarks: Catalina M5 vs. Apache 1.3.12 I wrote up a text file about benchmarking and comparing Tomcat-4.0-M5 (pre-release) and Apache 1.3.12. It's attached to this message. I wrote it for anyone who is interested (even non-Java-saavy people) to know how the raw content serving performance of Catalina and its built-in web server compares to that of Apache 1.3.12. It contains lots of information to help people understand some of the important differences between the two servers. Feedback, flames, reproduced test results, etc. are welcome! :) Cheers.
Re: Benchmarks
Hi Costin. [EMAIL PROTECTED] wrote: Hi Jason, First, it's really great to see the discussions about performance ! Your tests are extremely usefull I'm just returning the favor, after sitting through your ApacheCon session about the Tomcat performance/benchmarking.. I use ab and apache very often ( I used it as the main tool to tune tomcat 3.2 and now 3.3 ). It's nice, isn't it? I was going to write something like it, but since it was already there, I just used it. Like I said, it's got a few bugs, but it mostly gives useful information, and works pretty well. One thing that strikes me is the fact that I have a slower computer ( Celeron / 363 ) my numbers for apache ( with -c 60 ) are usually much smaller. I may know why this is. Before running my benchmarks, I played with ab quite a bit on both Apache and on Tomcat4. I wanted to tune the config files to give me the best performance that I could get on my machine. I ran lots of tests, changed config values (mainly threading or processing limits and defaults), and re-ran tests to see how the changes in the config files affected the performance outcomes. I eventually found what I believe to be about the most optimal settings *for my machine* for both Apache and Tomcat4. So, the configs I show in my tests have been tailored to my machine -- its CPU speed, RAM size, everything. Another machine that has different specs may not perform well with my machine's configs.. It may actually perform worse. I came to the conclusion that each different machine needs tailored config files, and that there probably is a process that one could follow to find the optimal settings for a machine. I've even considered writing some automated software to run overnight, all night long, benchmarking and tweaking the configs until the performance of the server on that machine is optimal. Do you realize how many servers could be substantially more efficient if everyone did that? Just an idea, but I think I want to do it.. ( it happens that I used the same test while rewriting the static servlet to StaticInterceptor ) I did another run, here is the sumarry: ( ab -c 60 -n 1 http://localhost/index.html): - Apache 1.3.12 - DEFAULT CONFIG, no change: First run: RPS: 344.44 Total: 67 172 637 Second run: RPS: 363.40 Total: 85 163 268 - Apache 1.3.12 - your config file First run: RPS: 261.27 Total:105 228 477 Second run: RPS: 253.63 Total: 81 234 402 I think this is good evidence that what I said above is in fact happening. By raising the number of processes on your machine (from the default) to the number of processes that are optimal for my machine, your machine gets bogged down a little by the weight of all those processes, and can't easily perform as well as it did before with a smaller number of processes. This also shows why it's a good idea that Apache's default config file sets the defaults the way it does. - Tomcat 3.3 - IBM JDK1.3 First run: RPS: 276.07 Total: 46 216 3265 Second: RPS: 345.55 Total: 17 172 228 - Tomcat 3.3 - Hotspot First: RPS: 287.5 Total: 53 206 764 Second: RPS: 308 Total: 42 193 1134 ( after another run the number get lower - almost same as IBM1.3 ) These numbers look pretty good.. did you also set the VM options like "-Xms96m -Xmx96m"? On my machine, that made the maximum times come down dramatically -- from the thousands of milliseconds to the hundreds of milliseconds. Of course, with a different Tomcat. :) It might do the same for yours though, again depending on your machine's specs. Of course, tomcat3.3 is not yet completely tuned, and static file handling is still far away from what it should be. Also, note that neither apache nor tomcat3.3 will cache the file - you should use MMapFile to compare with a container that uses caching. ( that adds about 20% performance to apache - since Linux is also caching the file accesses are not a very big factor ) I think Tomcat4 does cache the file, but also checks just to make sure that what it's caching hasn't changed on disk. ( BTW, last Apache2.0 I tried was almost 2x faster than 1.3 ) Yeah, that's about what I expect too. It can run in a multithreaded way just like Java servers do. So, no more heavyweight processes to lug around (not entirely sure this is a big deal on Linux, but on Solaris it is, and on other OSs I think it is). Cheers. -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org
Re: Kudos to Jason and his benchmarking report
part of a great guide to TCx performance and tuning ala Dean Gaudet's stuff on (Apache?) performance. That sounds like a much needed guide. Maybe a HOWTO? Now I need to study your stuff more closely and plan for the next round of measurement (and, in my case, modeling). Roy Have fun! -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org
Re: Now, am I stupid or what?
Pier P. Fumagalli wrote: Ok... So that's a personal preference, let's say... I don't like 'em because the look as hacks to me :) :) :) Sometimes hacks is all we've got. :) As for Windows, ppl can install cygwin and autoconf/automake work just fine there as well. I even compiled and installed wget on my Win98 box under cygwin with gcc/autoconf/automake/etc without any problems. Ok, but I don't want ppl to download cygwin just to compile the module, when MSVC and NMAKE work just fine... This is a bad assumption, since just because someone's running Windows does not mean they're willing to pay Micro$oft for an MSVC license, nor does everyone want to allocate the hard drive space for all of MSVC just so we can compile a few binaries for Windows. In my experience, cygwin is smaller, more UNIX-user friendly, compatible with bash and sh, and gives Windows a useful/featureful shell (finally!). I absolutely prefer cygwin/gcc over MSVC. And, of course, it works fine for UNIX build stuff, so it's a way to unify Windows, UNIX, and MacOS X for native code builds.. :) But anyway since for Windows all we want to do is building binaries and redistributing DLLs (never heard of anyone trying to compile under Win but me!), I have, and have used cygwin/gcc. And, with the Locomotive project, even though we built binaries for Windows and distributed them, users often wanted to compile the binaries themselves for whatever reason. It was still cost-free to do that as long as we used cygwin. The thing I hate about Auto* is that they somehow impose a check on a HUGE number of things that we'll never use... And they're hard as hell to maintain (once you've done an autoconf/automake you don't want to do it twice!) It isn't easy to maintain.. no. Even though it isn't as nice as Ant, I don't know of a better tool for building native code binaries. Do you know of a better one? -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org
Re: AccessLogValve performance fixes
Remy Maucherat wrote: Yep! That's a full 10 seconds slower than the new version, making the new version about 44% faster. Great ! I'll commit the patch later today. This test is single-threaded, but I think it still shows noticeable performance improvement. Something else that I could do with this that I haven't yet is make the valve able to buffer log file output. From my tests, it looks to me like this make the test run about 4 seconds faster, a maximum of 1.6% gain (not real big, but it's something). If it's really 4s out of 13s, isn't it more than 1.6% ? If the gain is another 4s, then it's significant, and I think we should go for it. Remy Okay, that's one way to look at it. I was thinking 4s out of 24s, but now that you mention it, it's now 4s out of 13s. So, I'll work on that too. About buffering, I was thinking that not everyone would want the output buffered.. If you're debugging and you're trying individual requests and looking at the log information for each request, and the log lines don't show up in the log file after you make the request, that can be annoying/puzzling to the person trying to debug. I thought it might be a good idea if you could configure the valve to buffer or not buffer. Buffering should probably be turned on as the default. But, as long as the config says something like 'buffering="true"' then at least people will take note that buffering is turned on for that log file (it can serve as a sort of a warning). So, by default, it'll be fast, and the buffering could be turned off. That would be nice -- as long as this switchable feature does not really degrade performance. Ideas? -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org
New Valve Tester and NullValve
In the process of optimizing AccessLogValve, I came to the conclusion that I needed a tester that would allow me to benchmark (and otherwise test) the valve without needing to run all of Catalina -- I needed to isolate just the valve so that I could get clean benchmark times. So, I thought about writing just a class that would let me instantiate the valve, and use it. But, after some looking at the code, I realized some things: 1) That it may not be easy to make the valve act the same as it would act in a regular Catalina Container without making something that acts much like a Container anyway. 2) Even if I could make something that acts like a Container, it wouldn't really be a Container, so my custom class would only be "faking it". 3) Maintaining a fake container to continue to be like the Catalina Containers wouldn't be easy, and it would certainly be pointless. 4) Making a new class that really *was* a Container didn't look that tough. 5) If I needed one of these, certainly someone else must have also wanted one. :) So, I set out to write a generic Valve tester. I wrote it, got it running, and used it for optimizing the AccessLogValve. Here's what I wrote: org.apache.catalina.valves.ValveTesterBase.java This is the base abstract class that is a Container that uses the Valve you wish to test. org.apache.catalina.valves.NullValve.java I needed this valve to be the basic functionality of the ValveTesterBase Container subclasses. It does absolutely nothing other than return control to the caller. This is good because it takes up basically no cpu time, and completes the Container's request pipeline. Then, I wrote one subclass of ValveTesterBase: org.apache.catalina.connector.http.AccessLogValveTester.java This class tests the AccessLogValve in one particular way, and has control over the environment in which the AccessLogValve operates. I had to place this class in the http connector package only because the HttpRequestImpl and HttpResponseImpl classes are not declared public! Should they be? With the first two classes, anyone should be able to easily make a valve tester that tests a valve in exactly the way they want to test it. The ValveTesterBase class is intentionally simple, and small. The AccessLogValveTester is a good example of a subclass that uses it. One idea I had about how ValveTesterBase could be improved is by writing and integrating a request traffic generator of some kind (maybe also abstract?) so that the request traffic can be more like the characteristics of real web traffic, and thus be a more real-world test of the valves. I have not begun coding this yet. It will need to be multithreaded, though. Also, in which package should this tester code reside, really? I'm aprehensive about mixing the tester code in with the regular Catalina code.. All feedback about this code is welcome! Cheers. -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org /* * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * "This product includes software developed by the *Apache Software Foundation (http://www.apache.org/)." *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software *Foundation" must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called "Apache" *nor may "Apache" appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS C
Re: [PROPOSAL] Tomcat 4.0 Milestone 5
Remy Maucherat wrote: Just so you know, I've been looking at the AccessLogValve, and am working on getting it into shape to be re-enabled in the default config. In the process, I'm writing a Valve tester so we can test and benchmark Valves. It's already running, but it's not quite ready for release yet.. I would like that by default it doesn't do any kind of pattern matching at all (unless one is explicitely specified), and just output the standard log. You're talking about the AccessLogValve itself, right? You want an AccessLogValve that doesn't do any fancy pattern stuff, but built only to do the common log format? Yes, that would sure help it to perform, wouldn't it? And, we could have another Valve that does the fancy log patterns of people want that feature. -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org
[TC4] ResourcesBase.setCheckInterval() bug
Hi guys!
In reading through the org.apache.catalina.resources package code, I found
a small omission from the ResourcesBase.setCheckInterval() method:
public void setCheckInterval(int checkInterval) {
// Perform the property update
int oldCheckInterval = this.checkInterval;
this.checkInterval = checkInterval;
support.firePropertyChange("checkInterval",
new Integer(oldCheckInterval),
new Integer(this.checkInterval));
// Start or stop the background thread (if necessary)
if (started) {
if ((oldCheckInterval 0) (this.checkInterval = 0))
threadStop();
else if ((oldCheckInterval = 0) (this.checkInterval 0))
threadStart();
}
}
At the end of this method, we changed the check interval, and then we
need to either start or stop the background thread that periodically
checks for resource updates. The code in this method handles the
following:
1. When the background thread is already running and we should be shutting
it down because the new check interval doesn't require a background
thread at all.
2. When the thread is supposedly already running, the old check interval
didn't require a background thread (really, an illegal state -- and
since
this code looks basically like my patch below, was this just bad
placement
of this code?), and the new check interval does require a background
thread.. In that case the code at least makes sure that we have
a reference to a thread.
But, what it doesn't handle is:
3. When the background thread isn't already running, the previous check
interval didn't require a background thread, and the new check interval
does require a background thread.. It should start one.
So, here's the patch I'd suggest:
280a281,284
else {
if ((oldCheckInterval = 0) (this.checkInterval 0))
threadStart();
}
Thanks!
--
Jason Brittain (415)354-6645
Software Engineer, Olliance Inc.http://www.Olliance.com
Current Maintainer, Locomotive Project http://www.Locomotive.org
Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug
Hi Remy.
Oops, yes, you're right about this (of course). I misunderstood the use
of the
"started" variable to mean whether or not the background thread was already
started, instead of whether the component's lifecycle had started. Sorry.
BTW: I really like the resources package! I can think of several useful
implementations that I'd like to use, like one for CVS, or one for JavaMail,
or ... lots more.
Remy Maucherat wrote:
At the end of this method, we changed the check interval, and then we
need to either start or stop the background thread that periodically
checks for resource updates. The code in this method handles the
following:
1. When the background thread is already running and we should be shutting
it down because the new check interval doesn't require a background
thread at all.
2. When the thread is supposedly already running, the old check interval
didn't require a background thread (really, an illegal state -- and
since
this code looks basically like my patch below, was this just bad
placement
of this code?), and the new check interval does require a background
thread.. In that case the code at least makes sure that we have
a reference to a thread.
But, what it doesn't handle is:
3. When the background thread isn't already running, the previous check
interval didn't require a background thread, and the new check interval
does require a background thread.. It should start one.
So, here's the patch I'd suggest:
280a281,284
else {
if ((oldCheckInterval = 0) (this.checkInterval 0))
threadStart();
}
The "started" flag indicates that the component has been started. It's
related to the thread state since the thread cannot be started if the
started flag is not set to true. The flag is set by the start() and stop()
method. If the component hasn't been started yet, I don't think it should
start the thread (or try to stop it).
Does it make sense (or did I miss something ?) ?
Remy (going back to optimizing the HTTP connector)
--
Jason Brittain
Software Engineer, Olliance Inc.http://www.Olliance.com
Current Maintainer, Locomotive Project http://www.Locomotive.org
Re: Tomcat 4.0 Milestone 4
In case you're interested, we've written a short document about Catalina's Features And Benefits (FAB) that is more geared for non-geeks (it's very marketingly-written :) that you may want to include with the M4 docs. I've attached it to this mail. It's a plain text version, but I'm sure it would look better as HTML. Let us know if there's anything inaccurate about the details it contains. It was written by William Abernathy ([EMAIL PROTECTED]) and myself. Let us know what you think. And, BTW, great work on making Catalina the first Servlet 2.3 compliant servlet container! Cheers! -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org "Craig R. McClanahan" wrote: Hey folks, I'm planning on cutting a fourth milestone of Tomcat 4.0 tomorrow (Wednesday) evening. This milestone will reflect all of the changes that occurred in the servlet 2.3 and JSP 1.2 specifications between public draft and proposed final draft (and there were a *bunch* of them), completion of the remaining new 2.3/1.2 functionality, and several bug fixes. This will be the last big push of spec-related functionality additions for Tomcat 4.0. Now, we can turn our attention more towards bug fixes and performance tuning. You can help in that process by downloading and playing with the Tomcat 4.0 milestone. I'd like to see us shake it out enough to be production quality by Christmas time. Besides bug fixing and tuning, I know of several pieces of functionality yet to be added that are being worked on, including: * Web connectors (using a new connector protocol called mod_warp that is aware of webapp configuration settings, so you will not have to configure things twice). * JNDI context support (like that used in J2EE servers) for the env-entry and resource-ref configuration parameters in the deployment descriptor. If you are interested in contributing to Tomcat 4.0, there is a "wish list" document in file "catalina/STATUS.html" in the jakarta-tomcat-4.0 source tree. Feel free to propose new ideas, or to volunteer to work on one of these. Craig McClanahan Features and Benefits of the Catalina Servlet Container Introduction Catalina is a new open source servlet container from the makers of Apache JServ, engineered to be the fastest, most flexible, and most modular servlet container available. Hosted by the Apache Software Foundation, the Catalina server software package project is SUN Microsystems's next-generation Java Servlet Container Reference Implementation. This text discusses Catalina's features and benefits. Modularly-Designed Servlet Container Core Open source servlet containers have not, historically, been designed to be modular. Modularity allows much of the container's core functionalities to be changed out seamlessly when different implementations are required. Catalina's servlet container core was designed to be made of modules, each of which has a well defined interface to the other core modules. Any module may be replaced at runtime by new implementations that still adhere to the core's interfaces. New implementations of these core modules support custom and/or extended features, including: - Direct pluggable integration with legacy systems - Diverse implementations of free or proprietary core components - Modular embedding of the Catalina servlet container into larger applications. Up to Date With the Latest Java Servlet Specification New development invariably drives new specification revisions. In addition to its full compliance with the featureful Java Servlet 2.2 Specification, Catalina's design is pushing servlet container functionality to new heights. Catalina's development has driven the Java Servlet 2.3 Specification, which is written to take advantage of new features that were first implemented as part of the Catalina servlet container. Catalina brings the enterprise the latest and greatest servlet functionality -- first, and for free. Full, Integrally-Designed Virtual Hosting Support Engineered from the outset to support a complete set of virtual hosting features, Catalina's core enjoys distinct advantages over servlet containers that have had to add virtual hosting. Having these features designed into the core makes the source code easier to understand, and makes these features easy and efficient to use. Catalina includes support for running multiple Web Applications per vhost. Internet providers and web hosting companies need this hard-to-find feature to help scale their servers to meet high demand for less cost. Featureful and Extensible Request Processing Catalina supports request filtering on multiple levels and better enables the separation of server and web application functions. This makes it much easier for an administrator to track web application usage, track server performance, and add custom
