Tomcat 5.5.10: APR-SSL doesn't work in chrooted UML
Hello! I'm trying to run Tomcat 5.5.10 [1] on user mode linux which is started in a chrooted environment but Tomcat hangs when initializing the SSL-Connector - i. e. the message org.apache.coyote.http11.Http11AprProtocol init does never show up in the log. When I try to connect to the SSL-port the TCP handshake is made but no data at all is transmitted. Everything runs fine if: - The UML-kernel is *not* started in a chroot environment. (!) - APR is used but SSL is turned off (ex. the Connector has set the SSLEngine config attribute to off). - APR isn't used at all. I don't have the slightest idea why it should matter whether UML is started in a chroot environment or not. To tell the truth, I don't have the slightest idea whether it's a bug in Tomcat, APR, Tomcat's native binding to APR, openssl, UML or if it's myself overlooking something absolutely obvious. Any proposals what I could do to track this one down? Regards mks [1] In fact, it is a nightly build I made on August 6. - but the official 5.5.10 binary behaves identically. System spec: - Gentoo Linux on both host and guest. - Host kernel: vanilla 2.6.12.4 with blaisorblade's skas-2.6.12-v8.2 patch. - Guest kernel: vanilla 2.6.12.4 with blaisorblade's uml-2.6.12-bs9 patch. - APR 1.1.1. - OpenSSL 0.9.7e. - 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)
Jason Brittain wrote: 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. :) It's really bad. APR might help a little. With gij 4.0.0, you can do gij -jar ./bin/bootstrap.jar gcjing select parts should make it much faster, but I'm lazy and didn't try. Rémy - 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
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), kaffe 1.1.5, probably others. 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. Well, if you try the only VM which doesn't work ;) Rémy - 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
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). For the rest, install the compat package. Rémy - 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
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, 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. 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. Rémy - 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
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. Rémy - 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: Tomcat and APR
Peter Lin wrote: yeah, I can do that. ... I assume if i grab the nightly for 5.5.x and APR1.1.x I should be ready to go. In the event I need some assistance, you going to be around Mladen :) ? Well, not at the midnight like your post was, but I'm sure it wasn't a midnight at your time zone :). I've done testing on SLES9/64 with JDK5 and current apr release from apache (apr-1.1.1). The performance is equal or APR is slightly faster, but what's more important is the scalability for keep-alive connections. Now you can have hundreds of keep-alive connections without going over the thread limit. Not sure how to test that, but I suppose that test for standard installation should include much higher maxThreads value then for APR implementation. One other thing. Use some unix for Tomcat, or you will need to patch the APR for windows. The reason is that the APR uses standard windows FD_SETSIZE that is 64. I did recompile the apr with setting the FD_SETSIZE to 16384 before including winsock2.h, so we don't have that limit. I did that because I thought that unixes has unlimited FD_SETSIZE, but it seems that the common value is 1024, so that is probably our limit for now. Think that we'll need multiple Poller threads if higher number is required. Anyhow don't test more then 1024 concurrent users at the moment, or 64 if using vanilla APR on windows. More about testing: Right now the code waits for 50ms (configurable or will be) after the request for another keep-alive request, and then goes to the poller if the client didn't provide the request. So that would be valuable to test actually. Let's say that client sends each request with keep-alive in a 100+ ms rate. Not sure if JMeter can make a pause between the requests, but ab can not, and that is what we need to measure basically, since it's more close to the real-world then simply hitting the Tomcat in a loop. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
At last week I use very successfull the httperf load tool to simulate sessions request. With httperf you can generate high load and it is easy to configure. You can configure think time between requests. But with session handling on, we see some corrupted requests. http://www.hpl.hp.com/personal/David_Mosberger/httperf.html Peter Mladen Turk schrieb: Peter Lin wrote: yeah, I can do that. ... I assume if i grab the nightly for 5.5.x and APR1.1.x I should be ready to go. In the event I need some assistance, you going to be around Mladen :) ? Well, not at the midnight like your post was, but I'm sure it wasn't a midnight at your time zone :). I've done testing on SLES9/64 with JDK5 and current apr release from apache (apr-1.1.1). The performance is equal or APR is slightly faster, but what's more important is the scalability for keep-alive connections. Now you can have hundreds of keep-alive connections without going over the thread limit. Not sure how to test that, but I suppose that test for standard installation should include much higher maxThreads value then for APR implementation. One other thing. Use some unix for Tomcat, or you will need to patch the APR for windows. The reason is that the APR uses standard windows FD_SETSIZE that is 64. I did recompile the apr with setting the FD_SETSIZE to 16384 before including winsock2.h, so we don't have that limit. I did that because I thought that unixes has unlimited FD_SETSIZE, but it seems that the common value is 1024, so that is probably our limit for now. Think that we'll need multiple Poller threads if higher number is required. Anyhow don't test more then 1024 concurrent users at the moment, or 64 if using vanilla APR on windows. More about testing: Right now the code waits for 50ms (configurable or will be) after the request for another keep-alive request, and then goes to the poller if the client didn't provide the request. So that would be valuable to test actually. Let's say that client sends each request with keep-alive in a 100+ ms rate. Not sure if JMeter can make a pause between the requests, but ab can not, and that is what we need to measure basically, since it's more close to the real-world then simply hitting the Tomcat in a loop. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Mladen Turk wrote: Peter Lin wrote: I've done testing on SLES9/64 with JDK5 and current apr release from apache (apr-1.1.1). The performance is equal or APR is slightly faster, but what's more important is the scalability for keep-alive connections. Now you can have hundreds of keep-alive connections without going over the thread limit. This wouldn't really happen, as keepalive gets a lot more aggressive (ie, timeout is shorter) and keepalive is disabled when the amount of busy threads gets too high. However, this does put some strain on schedulers (should be ok with a modern setup) and resource usage (allocating a thread and all its related resources used for processing isn't insignificant, so dedicating most of these threads to block on a read isn't that great). The point is to allow getting the benefits of keepalive (much better performance for page loading times and network usage) without the cost (besides the cost of keeping a socket open which obviously cannot be avoided). This should be good for one-machine web servers, and should make Tomcat more appealing for that usage. On the other end of the scalability scale, JK has issues if there are too many frontend servers, and actually anytime the amount of processors in Tomcat is not equal to the amount of processors on the front servers. The only workaround for this use is to have processors timeout, but the current implementation will be inefficient with that kind of setup. One other thing. Use some unix for Tomcat, or you will need to patch the APR for windows. The reason is that the APR uses standard windows FD_SETSIZE that is 64. I did recompile the apr with setting the FD_SETSIZE to 16384 before including winsock2.h, so we don't have that limit. I did that because I thought that unixes has unlimited FD_SETSIZE, but it seems that the common value is 1024, so that is probably our limit for now. Think that we'll need multiple Poller threads if higher number is required. Anyhow don't test more then 1024 concurrent users at the moment, or 64 if using vanilla APR on windows. That's the only problem I can see. Could this default value be changed unless there's a really good reason for it ? (from what I can see, higher values work well on my Windows) More about testing: Right now the code waits for 50ms (configurable or will be) after All the configuration should be ok now. This is the JMX view of the APR HTTP connector. Name: Catalina:type=ThreadPool,name=http-8080 modelerType: org.apache.tomcat.util.net.AprEndpoint serverSocketPool: 53067816 running: true firstReadTimeout: 100 soTimeout: 2 threadPriority: 5 port: 8080 currentThreadsBusy: 2 soLinger: -1 maxSpareThreads: 0 maxThreads: 150 pollerSize: 512 pollTime: 10 keepAliveCount: 0 tcpNoDelay: true minSpareThreads: 0 daemon: true paused: false backlog: 100 currentThreadCount: 2 name: http-8080 - firstReadTimeout (in ms): timeout before a socket goes to the poller - currentThreadsBusy: Number of workers doing some processing; it's always +1 compared to what is expected as the acceptor will get a new worker before calling accept on the server socket (so that there's no chance that an accepted socket could wait for a worker to become available) - pollerSize: Maximum amount of sockets which can be placed in the poller, which means the amount of connections which can be keptalive (previously, each one of these would have used a thread) - keepAliveCount: Number of sockets currently in the poller - pollTime (in microseconds): timeout for the poll call Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Well I've no problems with using APR if we could still use a pure Java implementation. Some may not have APR on their boxes, or an incorrect version of APR, or an invalid APR configuration (ie not multi-threaded). Remember mod_webapp and the reasons why it failed, ie too many peoples couldn't get the correct APR for there machine. So if we could make it configurable, via server.xml for example, using APR seems a great idea. On 4/14/05, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, Apologies if I missed it, but I've seen responses to Yoav's and Peter's posts, but I have yet to see anything about Jess' NIO question. Since I agree with his observations, I was wondering if a reponse was in the works? (I assume it'll say something like, Yes, a Java NIO solution could very well provide enough improvements, but APR is already written, fully-established, and field- tested.) Just curious. In addition to Remy's response, you may want to search the message archives for this list. We've discussed NIO many times in the past in good depth. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Henri Gomez wrote: Well I've no problems with using APR if we could still use a pure Java implementation. Some may not have APR on their boxes, or an incorrect version of APR, or an invalid APR configuration (ie not multi-threaded). Remember mod_webapp and the reasons why it failed, ie too many peoples couldn't get the correct APR for there machine. A the time of mod_webapp APR was not stable enough, now this has improved a lot. So if we could make it configurable, via server.xml for example, using APR seems a great idea. On 4/14/05, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, Apologies if I missed it, but I've seen responses to Yoav's and Peter's posts, but I have yet to see anything about Jess' NIO question. Since I agree with his observations, I was wondering if a reponse was in the works? (I assume it'll say something like, Yes, a Java NIO solution could very well provide enough improvements, but APR is already written, fully-established, and field- tested.) Just curious. In addition to Remy's response, you may want to search the message archives for this list. We've discussed NIO many times in the past in good depth. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
I've got no problem with APR stability but availability in the correct version for some OS, ie iSeries or ... BS2000 :) On 4/15/05, jean-frederic clere [EMAIL PROTECTED] wrote: Henri Gomez wrote: Well I've no problems with using APR if we could still use a pure Java implementation. Some may not have APR on their boxes, or an incorrect version of APR, or an invalid APR configuration (ie not multi-threaded). Remember mod_webapp and the reasons why it failed, ie too many peoples couldn't get the correct APR for there machine. A the time of mod_webapp APR was not stable enough, now this has improved a lot. So if we could make it configurable, via server.xml for example, using APR seems a great idea. On 4/14/05, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, Apologies if I missed it, but I've seen responses to Yoav's and Peter's posts, but I have yet to see anything about Jess' NIO question. Since I agree with his observations, I was wondering if a reponse was in the works? (I assume it'll say something like, Yes, a Java NIO solution could very well provide enough improvements, but APR is already written, fully-established, and field- tested.) Just curious. In addition to Remy's response, you may want to search the message archives for this list. We've discussed NIO many times in the past in good depth. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Henri Gomez wrote: I've got no problem with APR stability but availability in the correct version for some OS, ie iSeries or ... BS2000 :) Right there is also the thread libraries APR should use the same the JMV is using (no always easy to find). On 4/15/05, jean-frederic clere [EMAIL PROTECTED] wrote: Henri Gomez wrote: Well I've no problems with using APR if we could still use a pure Java implementation. Some may not have APR on their boxes, or an incorrect version of APR, or an invalid APR configuration (ie not multi-threaded). Remember mod_webapp and the reasons why it failed, ie too many peoples couldn't get the correct APR for there machine. A the time of mod_webapp APR was not stable enough, now this has improved a lot. So if we could make it configurable, via server.xml for example, using APR seems a great idea. On 4/14/05, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, Apologies if I missed it, but I've seen responses to Yoav's and Peter's posts, but I have yet to see anything about Jess' NIO question. Since I agree with his observations, I was wondering if a reponse was in the works? (I assume it'll say something like, Yes, a Java NIO solution could very well provide enough improvements, but APR is already written, fully-established, and field- tested.) Just curious. In addition to Remy's response, you may want to search the message archives for this list. We've discussed NIO many times in the past in good depth. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Peter Lin wrote: I'll wait until that's fixed and then run the full set of benchmarks. that way we'll have direct comparison. All right, the performance is now more or less decent, and polling seems to work. You can try testing it :) Mladen recommends APR 1.1. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
yeah, I can do that. ... I assume if i grab the nightly for 5.5.x and APR1.1.x I should be ready to go. In the event I need some assistance, you going to be around Mladen :) ? peter lin On 4/15/05, Remy Maucherat [EMAIL PROTECTED] wrote: Peter Lin wrote: I'll wait until that's fixed and then run the full set of benchmarks. that way we'll have direct comparison. All right, the performance is now more or less decent, and polling seems to work. You can try testing it :) Mladen recommends APR 1.1. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat and APR
Hi, 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. This will provide the following benefits (some small, others more significant): - zero GC IO API (APR is not object based) - flexible handling of socket reads/writes using pollers and non blocking IO - sendfile support Which will allow: - better scalability when using HTTP/1.1 keepalive, by eliminating the need for tying a thread blocked on an IO read (one or more (one on Unix, plenty on Windows) pollers will be used instead); this will allow certain single machine servers which couldn't use keealive in order to limit the amount of threads (to be able to have more simultaneous users) to benefit from the (large) performance benefits of keepalive - better performance and easier configuration when using AJP: one of the issues of AJP at the moment is that the number of AJP processors in Tomcat must be equal to the number of processors on the front end native servers, or keepalive has to be disabled (resulting in performance degradation); the benefit for AJP seems to actually be greater than for HTTP (special thanks to Mladen who explained to me the situation in detail) - efficient static file serving (not done yet) - (likely) better performance and reliability on free JVMs - probably slightly better performance (over NIO, Mladen measured 10%, while I measured 0%; as classic IO is a bit slower generally, I expect a small improvement); unfortunately, maximum throughput suffers (maximum throughput is measured by ab with keeplive enabled on localhost), as we cannot just block on the read until the next request comes; the benchmarks I use usually suck anyway ;) - SSL support through OpenSSL (not done right now) - access to certain useful native functions (detailed system status information, random data generation, etc) This would effectively make Tomcat more appealing to the lower end servers and, hopefully, web hosting companies (due to lower resource usage). Large sites would likely also benefit a little from the AJP improvements. The implementation would be an alternate endpoint implementation, replacing PoolTcpEndpoint. Alternate HTTP/1.1 processor and socket channel (for AJP) will be provided. Development required is actually fairly small (significant testing will be required, however). I didn't do the updated socket channel yet, but after 3 days of hacking, HTTP works (and the AJP stuff should be much faster to do). Now the tricky points: - is it appropriate for 5.5 ? I'd say yes, as it will be a separate independent implementation - will require APR, and a small JNI friendly wrapper library tentatively named libtcnative by Mladen (Windows binaries - and likely others - will be provided); portability should be good - we'll need to improve performance (and especially fix the kludge that is currently used to decide if a socket should be put inside a poller) Comments ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Overall this seems well and good as long as this is not the default in 5.5 (i.e. by default Tomcat should be pure Java and run anywhere with a good JVM without native code). To play devil's advocate for a moment, however, would use of Java NIO potentially make more sense for Tomcat, i.e. to take a step forward in terms of performance, etc, without requiring native code? [I'm not saying NIO covers all the bases APR would or is as fast. Rather wondering whether performance efforts should not remain in the pure Java space until that is truly exhausted.] -- Jess Holle Remy Maucherat wrote: Hi, 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. This will provide the following benefits (some small, others more significant): - zero GC IO API (APR is not object based) - flexible handling of socket reads/writes using pollers and non blocking IO - sendfile support Which will allow: - better scalability when using HTTP/1.1 keepalive, by eliminating the need for tying a thread blocked on an IO read (one or more (one on Unix, plenty on Windows) pollers will be used instead); this will allow certain single machine servers which couldn't use keealive in order to limit the amount of threads (to be able to have more simultaneous users) to benefit from the (large) performance benefits of keepalive - better performance and easier configuration when using AJP: one of the issues of AJP at the moment is that the number of AJP processors in Tomcat must be equal to the number of processors on the front end native servers, or keepalive has to be disabled (resulting in performance degradation); the benefit for AJP seems to actually be greater than for HTTP (special thanks to Mladen who explained to me the situation in detail) - efficient static file serving (not done yet) - (likely) better performance and reliability on free JVMs - probably slightly better performance (over NIO, Mladen measured 10%, while I measured 0%; as classic IO is a bit slower generally, I expect a small improvement); unfortunately, maximum throughput suffers (maximum throughput is measured by ab with keeplive enabled on localhost), as we cannot just block on the read until the next request comes; the benchmarks I use usually suck anyway ;) - SSL support through OpenSSL (not done right now) - access to certain useful native functions (detailed system status information, random data generation, etc) This would effectively make Tomcat more appealing to the lower end servers and, hopefully, web hosting companies (due to lower resource usage). Large sites would likely also benefit a little from the AJP improvements. The implementation would be an alternate endpoint implementation, replacing PoolTcpEndpoint. Alternate HTTP/1.1 processor and socket channel (for AJP) will be provided. Development required is actually fairly small (significant testing will be required, however). I didn't do the updated socket channel yet, but after 3 days of hacking, HTTP works (and the AJP stuff should be much faster to do). Now the tricky points: - is it appropriate for 5.5 ? I'd say yes, as it will be a separate independent implementation - will require APR, and a small JNI friendly wrapper library tentatively named libtcnative by Mladen (Windows binaries - and likely others - will be provided); portability should be good - we'll need to improve performance (and especially fix the kludge that is currently used to decide if a socket should be put inside a poller) Comments ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat and APR
Hi, The implementation would be an alternate endpoint implementation, replacing PoolTcpEndpoint. Alternate HTTP/1.1 processor and socket channel (for AJP) will be provided. Development required is actually fairly small (significant testing will be required, however). I didn't do the updated socket channel yet, but after 3 days of hacking, HTTP works (and the AJP stuff should be much faster to do). If it's truly independent, with an alternative PoolTcpEndpoint java class and some additional dependencies (APR and the specific JNI wrapper), then +1. At least for the first few releases, users should have the choice to use this technology, and not have it be required. I think that's what you meant anyways, just stating it for clarity. We can call it experimental, advertise it, and get 3rd party (e.g. Peter Lin) benchmarks. It'd be a very nice selling point to have a non-blocking IO option ;) - is it appropriate for 5.5 ? I'd say yes, as it will be a separate independent implementation I'd also say yes. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Yoav Shapira wrote: Hi, The implementation would be an alternate endpoint implementation, replacing PoolTcpEndpoint. Alternate HTTP/1.1 processor and socket channel (for AJP) will be provided. Development required is actually fairly small (significant testing will be required, however). I didn't do the updated socket channel yet, but after 3 days of hacking, HTTP works (and the AJP stuff should be much faster to do). If it's truly independent, with an alternative PoolTcpEndpoint java class and some additional dependencies (APR and the specific JNI wrapper), then +1. Yes, it is fully independent. I did end up modifying the Processor interface in coyote, but I think it is a useless interface. That's it. At least for the first few releases, users should have the choice to use this technology, and not have it be required. I think that's what you meant anyways, just stating it for clarity. I don't think it can ever be required. We'll see. We can call it experimental, advertise it, and get 3rd party (e.g. Peter Lin) benchmarks. It'd be a very nice selling point to have a non-blocking IO option ;) Since the API stays really simple, you can go crazy on non blocking stuff. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
if I have time this weekend, I'll try to run the same benchmarks on the latest code. is it included in the nightly build? if not, can someone post a build for me to benchmark on my system? peter On 4/14/05, Remy Maucherat [EMAIL PROTECTED] wrote: Hi, 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. This will provide the following benefits (some small, others more significant): - zero GC IO API (APR is not object based) - flexible handling of socket reads/writes using pollers and non blocking IO - sendfile support Which will allow: - better scalability when using HTTP/1.1 keepalive, by eliminating the need for tying a thread blocked on an IO read (one or more (one on Unix, plenty on Windows) pollers will be used instead); this will allow certain single machine servers which couldn't use keealive in order to limit the amount of threads (to be able to have more simultaneous users) to benefit from the (large) performance benefits of keepalive - better performance and easier configuration when using AJP: one of the issues of AJP at the moment is that the number of AJP processors in Tomcat must be equal to the number of processors on the front end native servers, or keepalive has to be disabled (resulting in performance degradation); the benefit for AJP seems to actually be greater than for HTTP (special thanks to Mladen who explained to me the situation in detail) - efficient static file serving (not done yet) - (likely) better performance and reliability on free JVMs - probably slightly better performance (over NIO, Mladen measured 10%, while I measured 0%; as classic IO is a bit slower generally, I expect a small improvement); unfortunately, maximum throughput suffers (maximum throughput is measured by ab with keeplive enabled on localhost), as we cannot just block on the read until the next request comes; the benchmarks I use usually suck anyway ;) - SSL support through OpenSSL (not done right now) - access to certain useful native functions (detailed system status information, random data generation, etc) This would effectively make Tomcat more appealing to the lower end servers and, hopefully, web hosting companies (due to lower resource usage). Large sites would likely also benefit a little from the AJP improvements. The implementation would be an alternate endpoint implementation, replacing PoolTcpEndpoint. Alternate HTTP/1.1 processor and socket channel (for AJP) will be provided. Development required is actually fairly small (significant testing will be required, however). I didn't do the updated socket channel yet, but after 3 days of hacking, HTTP works (and the AJP stuff should be much faster to do). Now the tricky points: - is it appropriate for 5.5 ? I'd say yes, as it will be a separate independent implementation - will require APR, and a small JNI friendly wrapper library tentatively named libtcnative by Mladen (Windows binaries - and likely others - will be provided); portability should be good - we'll need to improve performance (and especially fix the kludge that is currently used to decide if a socket should be put inside a poller) Comments ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Peter Lin wrote: if I have time this weekend, I'll try to run the same benchmarks on the latest code. is it included in the nightly build? if not, can someone post a build for me to benchmark on my system? We're going to have to resolve the issue I mentioned with keepalive before doing serious benchmarking. If you're on Linux, then it should be easy to test: build APR (I'll let Mladen precise any version requirement), and then build the native stuff in j-t-c/jni. Then make sure both libs are available to the JVM. APR is more portable than certified JVMs at the moment, although gcj-4 looks to be a big improvement (although not certified). Then use protocol=org.apache.coyote.http11.Http11AprProtocol on the connector element. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat and APR
Apologies if I missed it, but I've seen responses to Yoav's and Peter's posts, but I have yet to see anything about Jess' NIO question. Since I agree with his observations, I was wondering if a reponse was in the works? (I assume it'll say something like, Yes, a Java NIO solution could very well provide enough improvements, but APR is already written, fully-established, and field-tested.) Just curious. Jay Vertical Technology Group http://www.vtgroup.com/ -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, April 14, 2005 1:53 PM To: Tomcat Developers List Subject: Re: Tomcat and APR Peter Lin wrote: if I have time this weekend, I'll try to run the same benchmarks on the latest code. is it included in the nightly build? if not, can someone post a build for me to benchmark on my system? We're going to have to resolve the issue I mentioned with keepalive before doing serious benchmarking. If you're on Linux, then it should be easy to test: build APR (I'll let Mladen precise any version requirement), and then build the native stuff in j-t-c/jni. Then make sure both libs are available to the JVM. APR is more portable than certified JVMs at the moment, although gcj-4 looks to be a big improvement (although not certified). Then use protocol=org.apache.coyote.http11.Http11AprProtocol on the connector element. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Jess Holle wrote: Overall this seems well and good as long as this is not the default in 5.5 (i.e. by default Tomcat should be pure Java and run anywhere with a good JVM without native code). To play devil's advocate for a moment, however, would use of Java NIO potentially make more sense for Tomcat, i.e. to take a step forward in terms of performance, etc, without requiring native code? [I'm not saying NIO covers all the bases APR would or is as fast. Rather wondering whether performance efforts should not remain in the pure Java space until that is truly exhausted.] Yes, and the grass is always greener on the other side of the fence. For doing the same thing, it seems that APR is about as fast as NIO, and the API is really simple to use, with a trivial programming model. NIO has its uses, and is definitely a lot more engineered. What I hope is that the introduction of APR for the networking stack makes Tomcat sort of a Java Apache HTTP Server, which would make it more acceptable in production. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
I'll wait until that's fixed and then run the full set of benchmarks. that way we'll have direct comparison. peter On 4/14/05, Remy Maucherat [EMAIL PROTECTED] wrote: Peter Lin wrote: if I have time this weekend, I'll try to run the same benchmarks on the latest code. is it included in the nightly build? if not, can someone post a build for me to benchmark on my system? We're going to have to resolve the issue I mentioned with keepalive before doing serious benchmarking. If you're on Linux, then it should be easy to test: build APR (I'll let Mladen precise any version requirement), and then build the native stuff in j-t-c/jni. Then make sure both libs are available to the JVM. APR is more portable than certified JVMs at the moment, although gcj-4 looks to be a big improvement (although not certified). Then use protocol=org.apache.coyote.http11.Http11AprProtocol on the connector element. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat and APR
Hi, Apologies if I missed it, but I've seen responses to Yoav's and Peter's posts, but I have yet to see anything about Jess' NIO question. Since I agree with his observations, I was wondering if a reponse was in the works? (I assume it'll say something like, Yes, a Java NIO solution could very well provide enough improvements, but APR is already written, fully-established, and field- tested.) Just curious. In addition to Remy's response, you may want to search the message archives for this list. We've discussed NIO many times in the past in good depth. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
