DO NOT REPLY [Bug 35054] New: - warn if appBase is not existing as a File or directory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35054. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35054 Summary: warn if appBase is not existing as a File or directory Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] otherwise, it may very hard to find what is wrong -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35054] - warn if appBase is not existing as a File or directory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35054. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35054 --- Additional Comments From [EMAIL PROTECTED] 2005-05-25 10:04 --- Created an attachment (id=15162) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15162action=view) HostConfig.java.patch a little bit more user-friendly -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding working dynamically with mod_jk status?
Well it should be the final goal. A way to add a worker dynamically and also if possible an URI to worker. As such we could have a 24/24 7/7 dynamically manageable tomcat farm routeur (if we see the HTTP server as such) 2005/5/24, Mladen Turk [EMAIL PROTECTED]: [EMAIL PROTECTED] wrote: Any ideas or recommendations on this? Adding workers would be tricky because if member of load balancer it has to be known at startup time so that shared memory slot can be allocated. The only solution would be to edit the workers.properties file and then forcing the Apache to restart. 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]
DO NOT REPLY [Bug 35055] New: - Repeat warning about deprecated server.xml Loggers in 5.5 docs as well as 5.0 ?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35055. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35055 Summary: Repeat warning about deprecated server.xml Loggers in 5.5 docs as well as 5.0 ? Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Webapps:Documentation AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I've upgraded from 5.0.28 to 5.5.9, the same server.xml file works fine in both. Noticed that changing prefix/suffix attributes of EngineLogger now has no effect. Then noticed that http://jakarta.apache.org/tomcat/tomcat-5.0- doc/config/logger.html says that Loggers are deprecated in 5.5. Did not initially see this, as I switched to reading the 5.5 pages when I upgraded from 5.0 - could the same warning be added to 5.5 pages please, I think this would mean more people would see it. Also could the disappearance of Loggers in 5.5 be added to an upgrading to 5.5 page, along with other issues, and/or the 5.5 release notes? Again, this might help more people to find the info quicker. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35056] New: - Class loader should ignore obsolete jar or print its name if not found
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35056. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35056 Summary: Class loader should ignore obsolete jar or print its name if not found Product: Tomcat 5 Version: 5.5.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Configuration: Apache/2.0.40 (Red Hat Linux) mod_jk 1.2.8 Tomcat 5.5.7 Red Hat Linux 9 j2sdk-1_4_2_07 How to reproduce - Deploy your application with multiple jar files in your application's lib directory. - The contents of one jar file are not required by the application (obsolete). - The name of the obsolete jar file is such that it appears first in what I guess is Java's list() command. - Delete the obsolete jar file. - Request content of a servlet that has not been loaded before you deleted the obsolete file. Expected behavior: Tomcat should load the required class, or if it cannot load the class, then it should print a helpful error message. If the root cause is that a jar file cannot be opened, then the complete filename of the jar file should be printed in the error message. Actual behavior: It appears (I am guessing here) that Tomcat caches the list of jar files in the lib directory. It tries to open all files, including deleted ones. It crashes with two errors: 1) WARNING: Failed to open JAR java.util.zip.ZipException: No such file or directory There are two issues here that need to be addressed: a) Tomcat insists that a file that was available at deployment is available. It should ignore it if it does not exist. b) It does not print the filename of the file it tries to open. 2) SEVERE: Allocate exception for servlet your servlet here javax.servlet.ServletException: Error instantiating servlet your servlet class here Comment: It might be better that Tomcat tests for the existence of the file and if it does not exist then it should ignore it. If that is not possible e.g. because Tomcat keeps an index of the file's contents then it should print in the error message the complete filename of the file it can't find. Very much like in Java.io.FileNotFoundException where the filename is included in the stack trace. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35056] - Class loader should ignore obsolete jar or print its name if not found
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35056. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35056 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-05-25 11:20 --- Sorry, we will not implement that. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35054] - warn if appBase is not existing as a File or directory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35054. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35054 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #15162|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-05-25 11:30 --- Created an attachment (id=15163) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15163action=view) HostConfig.java.patch2 yet more user-friendliness (and an error less) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat not sending an ACK
Hi, I have been using tomcat to host my RTSP servlet, and I have written my own connector to accept RTSP commands, the only problem is, a client which I am writing the RTSP server for needs to receive a TCP ACK for the request it has sent. I have used 'Etherreal' to see what is going on, and it seems that tomcat is not sending the ACK. I think the problem could be that there is only one request message sent in the RTSP request, and maybe tomcat is waiting for more packets before it sends an ACK for them all? I tried setting keepalive to false to force an ACK, but this makes tomcat send a FIN, which closes the TCP connection, and this is no good. Is there a way I can force tomcat to send an ACK for each request sent? Any help much appreciated Thanks Robert Clarkson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11AprProtocol.java
remm2005/05/25 03:39:28
Modified:http11/src/java/org/apache/coyote/http11
Http11AprProtocol.java
Log:
- Add config of firstReadTimeout.
Revision ChangesPath
1.6 +9 -0
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11AprProtocol.java
Index: Http11AprProtocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11AprProtocol.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Http11AprProtocol.java22 May 2005 17:12:11 - 1.5
+++ Http11AprProtocol.java25 May 2005 10:39:28 - 1.6
@@ -278,6 +278,15 @@
setAttribute(port, + port);
}
+public int getFirstReadTimeout() {
+return ep.getFirstReadTimeout();
+}
+
+public void setFirstReadTimeout( int i ) {
+ep.setFirstReadTimeout(i);
+setAttribute(firstReadTimeout, + i);
+}
+
public boolean getUseSendfile() {
return ep.getUseSendfile();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11AprProcessor.java InternalAprInputBuffer.java
remm2005/05/25 05:45:38
Modified:http11/src/java/org/apache/coyote/http11
Http11AprProcessor.java InternalAprInputBuffer.java
Log:
- If the thread count gets too high, don't do any blocking read to start off
the request if no data is available, and put the socket in the poller.
Revision ChangesPath
1.13 +3 -1
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java
Index: Http11AprProcessor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- Http11AprProcessor.java 22 May 2005 17:12:11 - 1.12
+++ Http11AprProcessor.java 25 May 2005 12:45:38 - 1.13
@@ -751,6 +751,8 @@
int keepAliveLeft = maxKeepAliveRequests;
long soTimeout = endpoint.getSoTimeout();
+
+int limit = (endpoint.getMaxThreads() * 3) / 4;
boolean keptAlive = false;
boolean openSocket = false;
@@ -762,7 +764,7 @@
if( !disableUploadTimeout keptAlive soTimeout 0 ) {
Socket.timeoutSet(socket, soTimeout * 1000);
}
-if (!inputBuffer.parseRequestLine()) {
+if
(!inputBuffer.parseRequestLine(endpoint.getCurrentThreadsBusy() limit)) {
// This means that no data is available right now
// (long keepalive), so that the processor should be
recycled
// and the method should return true
1.7 +7 -1
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalAprInputBuffer.java
Index: InternalAprInputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalAprInputBuffer.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- InternalAprInputBuffer.java 15 May 2005 15:49:31 - 1.6
+++ InternalAprInputBuffer.java 25 May 2005 12:45:38 - 1.7
@@ -386,7 +386,7 @@
* @return true if data is properly fed; false if no data is available
* immediately and thread should be freed
*/
-public boolean parseRequestLine()
+public boolean parseRequestLine(boolean useAvailableData)
throws IOException {
int start = 0;
@@ -400,6 +400,9 @@
// Read new bytes if needed
if (pos = lastValid) {
+if (useAvailableData) {
+return false;
+}
// Do a simple read with a short timeout
bbuf.clear();
int nRead = Socket.recvbt
@@ -427,6 +430,9 @@
start = pos;
if (pos = lastValid) {
+if (useAvailableData) {
+return false;
+}
// Do a simple read with a short timeout
bbuf.clear();
int nRead = Socket.recvbt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Hi, The results of the AB benchmark configured with 20 concurrent clients are posted below, If somebody is interested in more configurations (from 20 to 1 concurrent clients) they are available at http://www.bsc.es/edragon/pdf/TestAb.tgz BTW, there is also available a comparison between Tomcat and the Hybrid (Tomcat+NIO) web servers at http://www.bsc.es/edragon/pdf/TestRubisDynamic.tgz. The comparison is based on the RUBiS benchmark and the httperf workload generator. Regards, -Vicenç ./ab -k -c 20 -n 200 http://pcbosch:8080/tomcat.gif Client: 2 way Xeon 2.4Ghz, 2GB RAM Server: 4 way Xeon 1.4Ghz, 2GB RAM Network: Gbit Java: build 1.5.0_03-b07 Tomcat 5.5.9 - - cument Path: /tomcat.gif Document Length:1934 bytes Concurrency Level: 20 Time taken for tests: 122.460403 seconds Complete requests: 200 Failed requests:0 Write errors: 0 Keep-Alive requests:1980006 Total transferred: 32937062 bytes HTML transferred: -426963428 bytes Requests per second:16331.81 [#/sec] (mean) Time per request: 1.225 [ms] (mean) Time per request: 0.061 [ms] (mean, across all concurrent requests) Transfer rate: 262.66 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 0.0 0 14 Processing: 00 2.5 0 636 Waiting:00 2.4 0 636 Total: 00 2.5 0 636 Percentage of the requests served within a certain time (ms) 50% 0 66% 1 75% 1 80% 1 90% 1 95% 2 98% 6 99% 11 100%636 (longest request) - - Tomcat Hybrid 5.5.9 - - Document Path: /tomcat.gif Document Length:1934 bytes Concurrency Level: 20 Time taken for tests: 282.264843 seconds Complete requests: 200 Failed requests:0 Write errors: 0 Keep-Alive requests:200 Total transferred: 33032704 bytes HTML transferred: -426967296 bytes Requests per second:7085.54 [#/sec] (mean) Time per request: 2.823 [ms] (mean) Time per request: 0.141 [ms] (mean, across all concurrent requests) Transfer rate: 114.28 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 0.0 0 1 Processing: 02 1.7 2 24 Waiting:02 1.7 2 24 Total: 02 1.7 2 24 Percentage of the requests served within a certain time (ms) 50% 2 66% 3 75% 4 80% 4 90% 5 95% 5 98% 6 99% 6 100% 24 (longest request) - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Am I reading the results correctly? tomcat 5.5.9 - 16,331.81/sec hybrid - 7,085.54/sec that means the hybrid connector is 2x slower. If those results are accurate, I would say the APR connector is much better choice. peter lin On 5/25/05, Vicenc Beltran Querol [EMAIL PROTECTED] wrote: Hi, The results of the AB benchmark configured with 20 concurrent clients are posted below, If somebody is interested in more configurations (from 20 to 1 concurrent clients) they are available at http://www.bsc.es/edragon/pdf/TestAb.tgz BTW, there is also available a comparison between Tomcat and the Hybrid (Tomcat+NIO) web servers at http://www.bsc.es/edragon/pdf/TestRubisDynamic.tgz. The comparison is based on the RUBiS benchmark and the httperf workload generator. Regards, -Vicenç ./ab -k -c 20 -n 200 http://pcbosch:8080/tomcat.gif Client: 2 way Xeon 2.4Ghz, 2GB RAM Server: 4 way Xeon 1.4Ghz, 2GB RAM Network: Gbit Java: build 1.5.0_03-b07 Tomcat 5.5.9 - - cument Path: /tomcat.gif Document Length:1934 bytes Concurrency Level: 20 Time taken for tests: 122.460403 seconds Complete requests: 200 Failed requests:0 Write errors: 0 Keep-Alive requests:1980006 Total transferred: 32937062 bytes HTML transferred: -426963428 bytes Requests per second:16331.81 [#/sec] (mean) Time per request: 1.225 [ms] (mean) Time per request: 0.061 [ms] (mean, across all concurrent requests) Transfer rate: 262.66 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 0.0 0 14 Processing: 00 2.5 0 636 Waiting:00 2.4 0 636 Total: 00 2.5 0 636 Percentage of the requests served within a certain time (ms) 50% 0 66% 1 75% 1 80% 1 90% 1 95% 2 98% 6 99% 11 100%636 (longest request) - - Tomcat Hybrid 5.5.9 - - Document Path: /tomcat.gif Document Length:1934 bytes Concurrency Level: 20 Time taken for tests: 282.264843 seconds Complete requests: 200 Failed requests:0 Write errors: 0 Keep-Alive requests:200 Total transferred: 33032704 bytes HTML transferred: -426967296 bytes Requests per second:7085.54 [#/sec] (mean) Time per request: 2.823 [ms] (mean) Time per request: 0.141 [ms] (mean, across all concurrent requests) Transfer rate: 114.28 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 0.0 0 1 Processing: 02 1.7 2 24 Waiting:02 1.7 2 24 Total: 02 1.7 2 24 Percentage of the requests served within a certain time (ms) 50% 2 66% 3 75% 4 80% 4 90% 5 95% 5 98% 6 99% 6 100% 24 (longest request) - - - 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]
DO NOT REPLY [Bug 35061] New: - Tomcat build fails with newest ant 1.6.4
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35061. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35061 Summary: Tomcat build fails with newest ant 1.6.4 Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Tomcat 5.5.9 build fails with the latest version of ant (1.6.4). Ant 1.6.2 does not seem to suffer this issue. The new ant implements a change (http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ ant/taskdefs/Move.java?r1=1.41.2.4r2=1.41.2.5) that prevents moving a directory onto another directory. It looks like this change has since been backed out (http://cvs.apache.org/viewcvs.cgi/ant/ src/main/org/apache/tools/ant/taskdefs/Move.java?r1=1.41.2.6r2=1.41.2.7) but it got into ant 1.6.4, and will be there until a new ant is released. Can the tomcat build be fixed to avoid running across this bug? Tomcat build fails with the following: ... -build-tomcat-dbcp: [copy] Copying 57 files to /Volumes/Data/jberry/Projects/darwinports/dports/java/tomcat5/work/ jakarta-tomcat-5.5.9-src/jakarta-tomcat-5/Repository/tomcat-deps [mkdir] Created dir: /Volumes/Data/jberry/Projects/darwinports/dports/java/tomcat5/work/jakarta- tomcat-5.5.9-src/jakarta-tomcat-5/Repository/tomcat-deps/src/java/org/apache/tomcat/dbcp BUILD FAILED /Volumes/Data/jberry/Projects/darwinports/dports/java/tomcat5/work/jakarta-tomcat-5.5.9-src/ jakarta-tomcat-5/build.xml:1867: The following error occurred while executing this line: /Volumes/Data/jberry/Projects/darwinports/dports/java/tomcat5/work/jakarta-tomcat-5.5.9-src/ jakarta-tomcat-5/build.xml:643: The following error occurred while executing this line: /Volumes/Data/jberry/Projects/darwinports/dports/java/tomcat5/work/jakarta-tomcat-5.5.9-src/ jakarta-tomcat-5/build.xml:655: The following error occurred while executing this line: /Volumes/Data/jberry/Projects/darwinports/dports/java/tomcat5/work/jakarta-tomcat-5.5.9-src/ jakarta-tomcat-5/build.xml:690: Cannot replace directory /Volumes/Data/jberry/Projects/ darwinports/dports/java/tomcat5/work/jakarta-tomcat-5.5.9-src/jakarta-tomcat-5/Repository/ tomcat-deps/src/java/org/apache/tomcat/dbcp with directory /Volumes/Data/jberry/Projects/ darwinports/dports/java/tomcat5/work/jakarta-tomcat-5.5.9-src/jakarta-tomcat-5/Repository/ tomcat-deps/src/java/org/apache/commons -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Peter Lin wrote: Am I reading the results correctly? tomcat 5.5.9 - 16,331.81/sec hybrid - 7,085.54/sec that means the hybrid connector is 2x slower. If those results are accurate, I would say the APR connector is much better choice. It's more complex than that. The APR connector has a trick to optimize pipelining (where a client would do many requests on a single connection, but with a small delay between requests - typically, it would happen when getting lots of images from a website). Maybe this could be added here as well. Removing this optimization will make piepelining performance go down as well. Note that Mladen tells me of more sendfile-like performance tricks that can't be matched by NIO (at least for now). Another test which could be done is comparing performance without the -k setting of ab (removing the impact of any pipelining opimization, but more of the overhead is then on the TCP stack rather than on the connector). I still don't like the proposed NIO solution, however, as it adds a lot of complexity to the default thread pool (which was complex already, but with those changes, it becomes black magic, and robustness will likely go down). If doing NIO, I think a much simpler thread pool structure should be used instead, like the APR endpoint does (even better, it could be a Java 5 version taking advantage of the new thread pool APIs). I expect Jean-Francois to live up to the hype and produce less experimental code ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35063] New: - Validation of HowTo Deploy (doc + example)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35063. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35063 Summary: Validation of HowTo Deploy (doc + example) Product: Tomcat 5 Version: 5.5.7 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Webapps:Documentation AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi, Because - there is a lot of informations on several documents for deploying a webapp in Tomcat 5.5 and often questions on the mailing list, - many things have changed in Tomcat 5.5, - I had no answer to my recent post on tomcat-user mailing list, I wrote a document HowTO deploy on a production server and an example to do this as standard and simple as possible. Can you help me to validate (correct and/or complete) this ? Eventually, could you integrate such a document in a future Tomcat documentation ? Notes : - The doc HowTo is in the tgz, under doc/HowtoDeployForProduction.html - The goal of this document is only to be a as simple as possible starting point for this theme. - If you don't want to integrate it, can you give me a validation ? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35063] - Validation of HowTo Deploy (doc + example)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35063. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35063 --- Additional Comments From [EMAIL PROTECTED] 2005-05-25 16:08 --- Created an attachment (id=15164) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15164action=view) Simple example + HowTo document -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35064] New: - Admin WebApp fails to open connectors when clicked.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35064. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35064 Summary: Admin WebApp fails to open connectors when clicked. Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Webapps:Administration AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] When I expand the Service and attempt to click on a connector I receive the following error: HTTP STATUS 500 Error retrieving attribute address My tomcat configuration is: ?xml version=1.0 encoding=ISO-8859-1? Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.mbeans.ServerLifecycleListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Listener className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/ !-- Global JNDI resources -- GlobalNamingResources Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / /GlobalNamingResources Service name=Catalina !-- Define a non-SSL HTTP/1.1 Connector on 10.0.2.81:80 -- Connector address=10.0.2.81 port=80 maxThreads=300 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true / !-- Define a SSL HTTP/1.1 Connector on 10.0.2.81:443 -- Connector address=10.0.2.81 port=443 maxThreads=300 minSpareThreads=25 maxSpareThreads=75 enableLookups=false acceptCount=100 connectionTimeout=2 disableUploadTimeout=true scheme=https secure=true clientAuth=false sslProtocol=SSL keystoreFile=certs/www_rapidclose_com.jks keystorePass=alpine/ !-- Define a non-SSL HTTP/1.1 Connector on 10.0.2.51:80 -- Connector address=10.0.2.51 port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true / !-- Define a SSL HTTP/1.1 Connector on 10.0.2.51:443 -- Connector address=10.0.2.51 port=8443 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false acceptCount=100 connectionTimeout=2 disableUploadTimeout=true scheme=https secure=true clientAuth=false sslProtocol=SSL keystoreFile=certs/apps.ks keystorePass=alpine/ Engine name=Catalina defaultHost=www.rapidclose.com Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ !-- Define the default virtual host for www.rapidclose.com -- Host name=10.0.2.81 appBase=websites/www_rapidclose_com/webapps unpackWARs=true autoDeploy=true Aliaswww.rapidclose.com/Alias !-- Log Access to host site -- Valve className=org.apache.catalina.valves.FastCommonAccessLogValve directory=logs prefix=rapidclose_access_ suffix=.log pattern=common resolveHosts=false/ /Host !-- Define the default virtual host for apps.sfsltd.com -- Host name=10.0.2.51 appBase=websites/apps_sfsltd_com/webapps unpackWARs=true autoDeploy=true
DO NOT REPLY [Bug 11563] - Authorization information not available at TOMCAT side (JSP: getRemoteUser())
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=11563. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=11563 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|RESOLVED|REOPENED Component|Webapps:Examples|Webapps:Examples Product|Tomcat 4|Tomcat 5 Resolution|WORKSFORME | Version|4.0.4 Final |Unknown --- Additional Comments From [EMAIL PROTECTED] 2005-05-25 16:43 --- This is still an issue. I have the problem with Tomcat 5.5.7 using the ISAPI redirector (not using apache HTTP). Kevin -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11563] - Authorization information not available at TOMCAT side (JSP: getRemoteUser())
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=11563. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=11563 --- Additional Comments From [EMAIL PROTECTED] 2005-05-25 16:44 --- This is still an issue. I have the problem with Tomcat 5.5.7 using the ISAPI redirector (not using apache HTTP). Kevin -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java Response.java
[EMAIL PROTECTED] wrote: billbarker2005/05/20 20:02:25 Modified:catalina/src/share/org/apache/catalina/connector Connector.java Response.java Log: Reverting previous patch in favor of the better one submitted by JFC No idea why but suddenly I'm getting the following when stopping the Tomcat with simple CTRL+C and AJP connector enabled. INFO: Pausing Coyote HTTP/1.1 on http-8080 May 25, 2005 4:46:53 PM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception (java.lang.NoSuchMethodError: org.apache.jk.core.MsgContext.getRequest()Ljava/lang/Object;) executing [EMAIL PROTECTED], terminating thread May 25, 2005 4:46:54 PM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina Any ideas why? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Automatic Response
Dear eBay member, Were sorry. We are not able to process your recent reply to our email. We are the processor for the email surveys for eBay and are not directly linked to the eBay customer service center. Please respond through the survey link imbedded in the original email you received from us. Thank you and we apologize for the inconvenience. eBay Survey Partner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11563] - Authorization information not available at TOMCAT side (JSP: getRemoteUser())
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=11563. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=11563 [EMAIL PROTECTED] changed: What|Removed |Added Severity|critical|normal Version|Unknown |5.5.7 --- Additional Comments From [EMAIL PROTECTED] 2005-05-25 17:49 --- It would appear that this can be resolved by turning off Tomcat Auth at the connector level. I was able to modify server.xml and add the 'tomcatAuthentication=false' setting. Perhaps a FAQ could help with this. !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 tomcatAuthentication=false enableLookups=false redirectPort=8443 protocol=AJP/1.3 / -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Hi, The APR connector has a trick to optimize pipelining (where a client would do many requests on a single connection, but with a small delay between requests - typically, it would happen when getting lots of images from a website). What's the trick? Are you trying to do blocking read operations with really short timeouts trying to create false pipelines, as I've already seen in other scenarios? Because it is only helpful when working in a really sinthetic environment (AB in a very-low-latency LAN). Have you ever tried the APR connector in a WAN? The Hybrid connector is already optimized for real pipelined HTTP requests. Anyway, as far as I know, the AB does not use HTTP pipelining. In my opinion, you're trusting in an unreal behavior of the clients, assuming very low time periods between one response is send and a new request is received for a given client. Maybe this could be added here as well. Removing this optimization will make piepelining performance go down as well. Note that Mladen tells me of more sendfile-like performance tricks that can't be matched by NIO (at least for now). I'm absolutely disconcerted. In your previous answeryou agreed that the AB test is not good for comparing two different architectural approaches. And you still wanna compare the performance of the hybrid architecture using it. But when I look for APR results on the net, I find that in the message 70876 (http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg70876.html) of this list that you're using JMeter and think-times in other experiments. Have you looked at any of the results I've post for realistic benchmarks? Why are you so obsessed with the AB results with concurrency level 20? Sorry, but I don't see the point on it... Using non-realistic benchmarks and very-oriented performance tricks only leads to winning few milliseconds in the response time of the server. But it's not a real benefit for the clients. When the server is overloaded (when performance improvements are really determinant), these benefits are negligible... In my opinion, following these development criterias is counterproductive and makes the server worse in the real world (where users put it into production). Surely, you disagree... Another test which could be done is comparing performance without the -k setting of ab (removing the impact of any pipelining opimization, but more of the overhead is then on the TCP stack rather than on the connector). If we move to an HTTP/1.0 scenario, why do we need to change the connector architecture? The multithreaded connector would be a good choice then... I still don't like the proposed NIO solution, however, as it adds a lot of complexity to the default thread pool (which was complex already, but with those changes, it becomes black magic, and robustness will likely go down). The thread pool is unmodified in the hybrid connector. The only modifications are done in the leaderfollower code, to use NIO operations. In my tests, the robustness has been supreme. At least, as good as the out-of-the-box Tomcat. If doing NIO, I think a much simpler thread pool structure should be used instead, like the APR endpoint does (even better, it could be a Java 5 version taking advantage of the new thread pool APIs). Is JNI simpler? I expect Jean-Francois to live up to the hype and produce less experimental code ;) Sure... :) I've one final question about the APR architecture. Have you implemented any kind of admission control mechanism on it? It's great to read your opinions... ;) Best, Vicenç - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java Response.java
Mladen Turk wrote: [EMAIL PROTECTED] wrote: billbarker2005/05/20 20:02:25 Modified:catalina/src/share/org/apache/catalina/connector Connector.java Response.java Log: Reverting previous patch in favor of the better one submitted by JFC No idea why but suddenly I'm getting the following when stopping the Tomcat with simple CTRL+C and AJP connector enabled. INFO: Pausing Coyote HTTP/1.1 on http-8080 May 25, 2005 4:46:53 PM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception (java.lang.NoSuchMethodError: org.apache.jk.core.MsgContext.getRequest()Ljava/lang/Object;) executing [EMAIL PROTECTED], terminating thread May 25, 2005 4:46:54 PM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina Any ideas why? Why do you think the changes in Connector and Response cause the problem? 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: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Vicenc Beltran Querol wrote: It's great to read your opinions... ;) Let's cut down on the broken record effect then: -1 for your code, it's not a clean implementation ;) (I end up with a smiley, since you did as well) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
On 5/25/05, Vicenc Beltran Querol [EMAIL PROTECTED] wrote: Hi, I'm absolutely disconcerted. In your previous answeryou agreed that the AB test is not good for comparing two different architectural approaches. And you still wanna compare the performance of the hybrid architecture using it. But when I look for APR results on the net, I find that in the message 70876 (http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg70876.html) of this list that you're using JMeter and think-times in other experiments. Have you looked at any of the results I've post for realistic benchmarks? Why are you so obsessed with the AB results with concurrency level 20? Sorry, but I don't see the point on it... Using non-realistic benchmarks and very-oriented performance tricks only leads to winning few milliseconds in the response time of the server. But it's not a real benefit for the clients. When the server is overloaded (when performance improvements are really determinant), these benefits are negligible... In my opinion, following these development criterias is counterproductive and makes the server worse in the real world (where users put it into production). Surely, you disagree... I'm not sure I agree with that statement. The reason for using apache AB for small files under 2K is that JMeter is unable to max out the server with tiny files. You can see the original number I produced here http://people.apache.org/~woolfel/tc_results.html. Since the bulk of my work the last 4 years has been with large applications handling millions of pageviews a day, I can safely say that most large deployment will rarely exceed 50 concurrent requests for extended period of time. this is just my experience on real applications, but we generally buffer the entire page and then send it in one shot. this is done for several reasons. 1. WAN latency - as you already stated 2. improve accuracy of performance logging. we log the page generation to make sure we know exactly how much time is spent for the query, page markup and transfering the data. 3. allows us to track network bottleneck more accurately In my mind, the argument for tomcat supporting 1000 concurrent connections for an extended period of time isn't valid from my experience. There's typically a large cluster of servers that are load balanced behind a load balancing router. For me, throughput is far more important because most the images and files range from 5-15K in size. In these cases, maximizing throughput is more important. So small sites trying to deal with the /. effect, it's not worth it. I say that because the network will die long before tomcat will. Any site with serious performance requirements will host at a tier 1 provider and have a cluster of servers. small personal sites are shared hosted and often don't have enough bandwidth. my bias .02 cents. peter lin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Peter Lin wrote: I'm not sure I agree with that statement. The reason for using apache AB for small files under 2K is that JMeter is unable to max out the server with tiny files. You can see the original number I produced here http://people.apache.org/~woolfel/tc_results.html. Since the bulk of my work the last 4 years has been with large applications handling millions of pageviews a day, I can safely say that most large deployment will rarely exceed 50 concurrent requests for extended period of time. this is just my experience on real applications, but we generally buffer the entire page and then send it in one shot. this is done for several reasons. 1. WAN latency - as you already stated 2. improve accuracy of performance logging. we log the page generation to make sure we know exactly how much time is spent for the query, page markup and transfering the data. 3. allows us to track network bottleneck more accurately In my mind, the argument for tomcat supporting 1000 concurrent connections for an extended period of time isn't valid from my experience. There's typically a large cluster of servers that are load balanced behind a load balancing router. For me, throughput is far more important because most the images and files range from 5-15K in size. In these cases, maximizing throughput is more important. So small sites trying to deal with the /. effect, it's not worth it. I say that because the network will die long before tomcat will. Any site with serious performance requirements will host at a tier 1 provider and have a cluster of servers. small personal sites are shared hosted and often don't have enough bandwidth. Yes, all this stuff is not really that useful in the real world in the end, and is mostly an answer to non blocking IO hype (which I find quite annoying). The actual benefits are: - better resource efficiency for small servers (hopefully allowing eventually a larger market share for Java web servers), but indeed it's not going to help in front of /. - all the other APR features which are really useful and not provided by the core Java platform - a lot more efficient for certain proxying scenarios (AJP mostly, but HTTP can have benefits too) - having maximum throughput is very important for this scenario, and is why I want maximum throughput - a lot more efficient for large static files (ex: serving media) due to sendfile Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java Response.java
jean-frederic clere wrote: Mladen Turk wrote: INFO: Pausing Coyote HTTP/1.1 on http-8080 May 25, 2005 4:46:53 PM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception (java.lang.NoSuchMethodError: org.apache.jk.core.MsgContext.getRequest()Ljava/lang/Object;) executing [EMAIL PROTECTED], terminating thread May 25, 2005 4:46:54 PM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina Any ideas why? Why do you think the changes in Connector and Response cause the problem? If I would have an idea I wouldn't ask 'Any ideas why?' :). Anyhow seems the problem with MsgContext.java when Bill changed the : -public final Object getRequest() +public final Request getRequest() Think that down the classtree getRequest() is still considered to return the Ljava/lang/Object. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
I took a look at the AB and Rubis numbers. Honestly I don't understand the rubis graphs. From the AB results, it looks like the connect, processing and wait times are lower for the hybrid. That's a good achievement and congrats to you on that. I'm not convinced of the benefit of the hybrid approach over APR. if both are equal, then it might be good to have both as options. it's nice to be able to support /. effect, but in reality that's achieved by distributing servers across multiple hosting facilities. It's not achieved through hosting a website on a single quad server supporting 10K concurrent connections. I'm not a committer, so I don't have a say in what goes into tomcat. thanks for researching NIO and taking time to post these results. peter lin On 5/25/05, Vicenc Beltran Querol [EMAIL PROTECTED] wrote: Hi, The results of the AB benchmark configured with 20 concurrent clients are posted below, If somebody is interested in more configurations (from 20 to 1 concurrent clients) they are available at http://www.bsc.es/edragon/pdf/TestAb.tgz BTW, there is also available a comparison between Tomcat and the Hybrid (Tomcat+NIO) web servers at http://www.bsc.es/edragon/pdf/TestRubisDynamic.tgz. The comparison is based on the RUBiS benchmark and the httperf workload generator. Regards, -Vicenç ./ab -k -c 20 -n 200 http://pcbosch:8080/tomcat.gif Client: 2 way Xeon 2.4Ghz, 2GB RAM Server: 4 way Xeon 1.4Ghz, 2GB RAM Network: Gbit Java: build 1.5.0_03-b07 Tomcat 5.5.9 - - cument Path: /tomcat.gif Document Length:1934 bytes Concurrency Level: 20 Time taken for tests: 122.460403 seconds Complete requests: 200 Failed requests:0 Write errors: 0 Keep-Alive requests:1980006 Total transferred: 32937062 bytes HTML transferred: -426963428 bytes Requests per second:16331.81 [#/sec] (mean) Time per request: 1.225 [ms] (mean) Time per request: 0.061 [ms] (mean, across all concurrent requests) Transfer rate: 262.66 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 0.0 0 14 Processing: 00 2.5 0 636 Waiting:00 2.4 0 636 Total: 00 2.5 0 636 Percentage of the requests served within a certain time (ms) 50% 0 66% 1 75% 1 80% 1 90% 1 95% 2 98% 6 99% 11 100%636 (longest request) - - Tomcat Hybrid 5.5.9 - - Document Path: /tomcat.gif Document Length:1934 bytes Concurrency Level: 20 Time taken for tests: 282.264843 seconds Complete requests: 200 Failed requests:0 Write errors: 0 Keep-Alive requests:200 Total transferred: 33032704 bytes HTML transferred: -426967296 bytes Requests per second:7085.54 [#/sec] (mean) Time per request: 2.823 [ms] (mean) Time per request: 0.141 [ms] (mean, across all concurrent requests) Transfer rate: 114.28 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 0.0 0 1 Processing: 02 1.7 2 24 Waiting:02 1.7 2 24 Total: 02 1.7 2 24 Percentage of the requests served within a certain time (ms) 50% 2 66% 3 75% 4 80% 4 90% 5 95% 5 98% 6 99% 6 100% 24 (longest request) - - - 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: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Remy Maucherat wrote: In my mind, the argument for tomcat supporting 1000 concurrent connections for an extended period of time isn't valid from my experience. - all the other APR features which are really useful and not provided by the core Java platform Actually I just read a perfect use case scenario request for the new APR connector on [EMAIL PROTECTED] With only couple of threads all the 1000 connections could be handled without having 1000 threads. Users are connecting to the solution by invoking a servlet (runned by tomcat). If a user is auhentified, then I use HTTPServletResponse object (in the service method) to get the Outputstream of that object = HTTPServletResponse.getoutputstream) Then this stream will be use to handle communications between my client application and my custom Server Process (I need to send real time informations through this canal). Important = A client session can last several hours, so the life of the servlet is set to time infinite . In fact I had the idea delegate socket connection managment, to tomcat engine, by setting servlet life time to infinite. Is it a good way to do, or should I use a socket pooling algorithm (actualy, the server can freeze, after unregular amout of times, time for writing operation in the Output stream can increase until being totaly unusuable, I have to close, and reconnect) The objective is to handle more than 1000 client sessions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java Response.java
- Original Message - From: Mladen Turk [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Wednesday, May 25, 2005 9:41 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java Response.java jean-frederic clere wrote: Mladen Turk wrote: INFO: Pausing Coyote HTTP/1.1 on http-8080 May 25, 2005 4:46:53 PM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception (java.lang.NoSuchMethodError: org.apache.jk.core.MsgContext.getRequest()Ljava/lang/Object;) executing [EMAIL PROTECTED], terminating thread May 25, 2005 4:46:54 PM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina Any ideas why? Why do you think the changes in Connector and Response cause the problem? If I would have an idea I wouldn't ask 'Any ideas why?' :). Anyhow seems the problem with MsgContext.java when Bill changed the : -public final Object getRequest() +public final Request getRequest() Think that down the classtree getRequest() is still considered to return the Ljava/lang/Object. Doing a clean build of j-t-c/jk/java should fix it. MsgContext isn't referenced outside of there. This is actually changed as part of Mark's Form-auth POST-replay, not the Connector/Response buffering. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java Response.java
Bill Barker wrote: Doing a clean build of j-t-c/jk/java should fix it. MsgContext isn't referenced outside of there. I'm doing 'ant checkout ant'. This is actually changed as part of Mark's Form-auth POST-replay, not the Connector/Response buffering. OK. Will try the clean build. Thanks, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding working dynamically with mod_jk status?
Is this still true if we were to define extra workers that are marked as disabled at startup? Could we then point them to any new servers as they are added and enable them without a restart? I know it's not very clean, but would it work? We'd *really* like to find a way around having to force a restart. thanks! David |-+ | | Mladen Turk | | | [EMAIL PROTECTED]| | | | | || | | 05/24/2005 02:55 | | | PM | | | Please respond to| | | Tomcat | | | Developers List | | || |-+ ---| | | | To: Tomcat Developers List tomcat-dev@jakarta.apache.org | | cc: | | Subject: Re: Adding working dynamically with mod_jk status? | ---| [EMAIL PROTECTED] wrote: Any ideas or recommendations on this? Adding workers would be tricky because if member of load balancer it has to be known at startup time so that shared memory slot can be allocated. The only solution would be to edit the workers.properties file and then forcing the Apache to restart. 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]
DO NOT REPLY [Bug 35063] - Validation of HowTo Deploy (doc + example)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35063. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35063 --- Additional Comments From [EMAIL PROTECTED] 2005-05-25 19:26 --- Created an attachment (id=15169) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15169action=view) Doc+example reviewed thanks to new re-deploy solution -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Mladen Turk wrote: Actually I just read a perfect use case scenario request for the new APR connector on [EMAIL PROTECTED] With only couple of threads all the 1000 connections could be handled without having 1000 threads. Actually, it seems a lot more a case of using the servlet API in a way it was not designed for. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Hi Peter, I took a look at the AB and Rubis numbers. Honestly I don't understand the rubis graphs. You can find an explanation about the httperf numbers on the man page of Httperf, or looking at http://www.hpl.hp.com/personal/David_Mosberger/httperf.html. Rubis is the dynamic application used for the test. If you are interested on the Rubis benchmark we can send to you a war archive with the aplication and the file with the request distribution used to generate the workload. From the AB results, it looks like the connect, processing and wait times are lower for the hybrid. That's a good achievement and congrats to you on that. I'm not convinced of the benefit of the hybrid approach over APR. if both are equal, then it might be good to have both as options. it's nice to be able to support /. effect, but in reality that's achieved by distributing servers across multiple hosting facilities. It's not achieved through hosting a website on a single quad server supporting 10K concurrent connections. I'm not a committer, so I don't have a say in what goes into tomcat. thanks for researching NIO and taking time to post these results. It has been a pleasure to post this information, and to receive constructive and technically-reasoned answers like yours. Deciding which parameters define the performance of a server is a great and never-ending discussion topic. Anyway, feel free to send my any questions you may have about the benchmarking environment I've used for my experiments. By the way, this is my last post about this topic. I've perfectly understood Remy's messages (in the list and in my personal address), so I will not waste your time anymore. Sincerely, Vicenç peter lin On 5/25/05, Vicenc Beltran Querol [EMAIL PROTECTED] wrote: Hi, The results of the AB benchmark configured with 20 concurrent clients are posted below, If somebody is interested in more configurations (from 20 to 1 concurrent clients) they are available at http://www.bsc.es/edragon/pdf/TestAb.tgz BTW, there is also available a comparison between Tomcat and the Hybrid (Tomcat+NIO) web servers at http://www.bsc.es/edragon/pdf/TestRubisDynamic.tgz. The comparison is based on the RUBiS benchmark and the httperf workload generator. Regards, -Vicenç ./ab -k -c 20 -n 200 http://pcbosch:8080/tomcat.gif Client: 2 way Xeon 2.4Ghz, 2GB RAM Server: 4 way Xeon 1.4Ghz, 2GB RAM Network: Gbit Java: build 1.5.0_03-b07 Tomcat 5.5.9 - - cument Path: /tomcat.gif Document Length:1934 bytes Concurrency Level: 20 Time taken for tests: 122.460403 seconds Complete requests: 200 Failed requests:0 Write errors: 0 Keep-Alive requests:1980006 Total transferred: 32937062 bytes HTML transferred: -426963428 bytes Requests per second:16331.81 [#/sec] (mean) Time per request: 1.225 [ms] (mean) Time per request: 0.061 [ms] (mean, across all concurrent requests) Transfer rate: 262.66 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 0.0 0 14 Processing: 00 2.5 0 636 Waiting:00 2.4 0 636 Total: 00 2.5 0 636 Percentage of the requests served within a certain time (ms) 50% 0 66% 1 75% 1 80% 1 90% 1 95% 2 98% 6 99% 11 100%636 (longest request) - - Tomcat Hybrid 5.5.9 - - Document Path: /tomcat.gif Document Length:1934 bytes Concurrency Level: 20 Time taken for tests: 282.264843 seconds Complete requests: 200 Failed requests:0 Write errors: 0 Keep-Alive requests:200 Total transferred: 33032704 bytes HTML transferred: -426967296 bytes Requests per second:7085.54 [#/sec] (mean) Time per request: 2.823 [ms] (mean) Time per request: 0.141 [ms] (mean, across all concurrent requests) Transfer rate: 114.28 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 0.0 0 1 Processing: 02 1.7 2 24 Waiting:02 1.7 2 24 Total: 02 1.7 2 24 Percentage of the requests served within a certain time (ms) 50% 2 66% 3 75% 4 80% 4 90%
Re: Adding working dynamically with mod_jk status?
[EMAIL PROTECTED] wrote: Is this still true if we were to define extra workers that are marked as disabled at startup? Could we then point them to any new servers as they are added and enable them without a restart? I know it's not very clean, but would it work? It will work if you know the hostname and the port that new server will have in advance. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Hi, By the way, this is my last post about this topic. I've perfectly understood Remy's messages (in the list and in my personal address), so I will not waste your time anymore. It was far from a waste of time. Please don't hesitate to contribute again in performance tuning or other areas. Hopefully we'll hear from you again, Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding working dynamically with mod_jk status?
On 5/25/05, [EMAIL PROTECTED] wrote: Is this still true if we were to define extra workers that are marked as disabled at startup? Could we then point them to any new servers as they are added and enable them without a restart? I know it's not very clean, but would it work? We'd *really* like to find a way around having to force a restart. Have you seen if a graceful restart of Apache works for you? Graceful restarts of Apache have worked for me in the past to add new workers without dropping requests. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35079] New: - Should be able to specify DNS lookup timeout
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35079. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35079 Summary: Should be able to specify DNS lookup timeout Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I want to set enableLookups=true, resolveHosts=true but with a timeout setting of 100ms. I expect that if the DNS does not reply within 100ms, Tomcat should log the IP address instead. From actual experience, I have noticed that if I don't get a reply within 100ms, the DNS is going to fail the lookup anyway (and this takes 5-20 seconds to come back) so I might as well fail it right away. I cannot enable resolveHosts with the current behavior because I get very poor performance on IPs where lookup fails (and results in a 5-20 seconds delay per request). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
