cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
jfclere 2005/05/04 00:04:30
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
Log:
When the file comes from a resource fileEncoding was not working.
The default beahviour is unchanged: the file is send without a conversion.
Revision ChangesPath
1.37 +11 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- DefaultServlet.java 2 May 2005 16:52:10 - 1.36
+++ DefaultServlet.java 4 May 2005 07:04:30 - 1.37
@@ -1725,6 +1725,16 @@
if (cacheEntry.resource != null) {
byte buffer[] = cacheEntry.resource.getContent();
if (buffer != null) {
+if (fileEncoding != null
+cacheEntry.attributes.getMimeType()!=null
+cacheEntry.attributes.getMimeType().equals(text/html))
{
+/* the binary have to be converted from fileEncoding
to UTF-8 */
+try {
+String str = new String(buffer, fileEncoding);
+buffer = str.getBytes(UTF-8);
+} catch (Exception e) {
+}
+}
ostream.write(buffer, 0, buffer.length);
return;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
jfclere 2005/05/04 00:30:24
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
Allow to use properties in native encoding.
In EBCDIC Environments the FileInputStream is localized but not the
ByteArrayInputStream therefore loading a properties from such
a file using the WebappClassLoader class loader failed.
Revision ChangesPath
1.49 +32 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- WebappClassLoader.java30 Mar 2005 13:01:00 - 1.48
+++ WebappClassLoader.java4 May 2005 07:30:24 - 1.49
@@ -354,6 +354,11 @@
*/
protected boolean hasExternalRepositories = false;
+/**
+ * need conversion for properties files
+ */
+protected boolean needConvert = false;
+
/**
* All permission.
@@ -1444,6 +1449,15 @@
public void start() throws LifecycleException {
started = true;
+String encoding = null;
+try {
+encoding = System.getProperty(file.encoding);
+} catch (Exception e) {
+return;
+}
+if (encoding.indexOf(EBCDIC)!=-1) {
+needConvert = true;
+}
}
@@ -1695,6 +1709,8 @@
Resource resource = null;
+boolean fileNeedConvert = false;
+
for (i = 0; (entry == null) (i repositoriesLength); i++) {
try {
@@ -1728,6 +1744,12 @@
return null;
}
+if (needConvert) {
+if (path.endsWith(.properties)) {
+fileNeedConvert = true;
+}
+}
+
// Register the full path for modification checking
// Note: Only syncing on a 'constant' object is needed
synchronized (allPermission) {
@@ -1855,8 +1877,8 @@
byte[] binaryContent = new byte[contentLength];
+int pos = 0;
try {
-int pos = 0;
while (true) {
int n = binaryStream.read(binaryContent, pos,
@@ -1874,6 +1896,14 @@
return null;
}
+if (fileNeedConvert) {
+String str = new String(binaryContent,0,pos);
+try {
+binaryContent = str.getBytes(UTF-8);
+} catch (Exception e) {
+return null;
+}
+}
entry.binaryContent = binaryContent;
// The certificates are only available after the JarEntry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Initial test of APR on Solaris
Bill Barker wrote: I can get the test to finish if I synchronize around the 'Poll.poll' statement in the Poller. However, doing this sends the perfomance right through the floor :(. I'm guessing it's a problem with doing an add and/or remove (most likely remove, since it hangs when test threads are finishing) at the same time that it's in the middle of a poll. Yes, you are correct with that. Most APR poll implementations are not thread safe. Think we'll need to add some sort of queue so that Poll.add, Poll.remove are done in the same thread as Poll.poll. If you had a faster box this probably would not be observed :). The problem is that we are syncing .add and .remove, but the .poll call if not thread safe can cause a problems. I'll play with that to see how it can be done in the most efficient way. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project jakarta-tomcat-jk-ant (in module jakarta-tomcat-connectors) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-tomcat-jk-ant has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat-jk-ant : Connectors to various web servers Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-ant/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [jkant.jar] identifier set to project name -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-ant/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-ant.html Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-ant (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only jkant [Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar - Buildfile: build.xml BUILD FAILED java.lang.NoClassDefFoundError: org/xml/sax/ext/Attributes2 at org.apache.xerces.parsers.AbstractSAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) at org.apache.tools.ant.util.JAXPUtils.newSAXParser(JAXPUtils.java:212) at org.apache.tools.ant.util.JAXPUtils.getNamespaceXMLReader(JAXPUtils.java:169) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:187) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:140) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:90) at org.apache.tools.ant.Main.runBuild(Main.java:653) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.Main.start(Main.java:150) at org.apache.tools.ant.Main.main(Main.java:240) Total time: 0 seconds java.lang.NoClassDefFoundError: org/xml/sax/ext/Attributes2 at org.apache.xerces.parsers.AbstractSAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) at org.apache.tools.ant.util.JAXPUtils.newSAXParser(JAXPUtils.java:212) at org.apache.tools.ant.util.JAXPUtils.getNamespaceXMLReader(JAXPUtils.java:169) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:187) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:140) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:90) at org.apache.tools.ant.Main.runBuild(Main.java:653) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.Main.start(Main.java:150) at org.apache.tools.ant.Main.main(Main.java:240) org/xml/sax/ext/Attributes2 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-ant/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-ant/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 3104052005, brutus:brutus-public:3104052005 Gump E-mail Identifier (unique within run) #31. -- Apache Gump
[EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-tomcat-jk-native has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 132 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat-jk-native : Connectors to various web servers Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: make [Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native] - Making all in common make[1]: Entering directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' /bin/sh /usr/local/gump/public/workspace/apache-httpd/dest-04052005/build/libtool --silent --mode=compile gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-04052005/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/usr/local/gump/public/workspace/apr/dest-04052005/include/apr-1 -g -O2 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I /opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c /usr/local/gump/public/workspace/apache-httpd/dest-04052005/build/libtool: /usr/local/gump/public/workspace/apache-httpd/dest-04052005/build/libtool: No such file or directory make[1]: *** [jk_ajp12_worker.lo] Error 127 make[1]: Leaving directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' make: *** [all-recursive] Error 1 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 3104052005, brutus:brutus-public:3104052005 Gump E-mail Identifier (unique within run) #40. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - 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/servlets DefaultServlet.java
[EMAIL PROTECTED] wrote: jfclere 2005/05/04 00:04:30 Modified:catalina/src/share/org/apache/catalina/servlets DefaultServlet.java Log: When the file comes from a resource fileEncoding was not working. The default beahviour is unchanged: the file is send without a conversion. This kind of operation is extremely costly (will likely make fileEncoding a problematic option, as imagine doing it on a 1MB text file), and seems wrong: the purpose of the byte based sending is to send the resource unchanged. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Initial test of APR on Solaris
Bill Barker wrote: I can get the test to finish if I synchronize around the 'Poll.poll' statement in the Poller. However, doing this sends the perfomance right through the floor :(. I'm guessing it's a problem with doing an add and/or Yes, it's probably too extreme syncing (100 ms locking) ;) remove (most likely remove, since it hangs when test threads are finishing) at the same time that it's in the middle of a poll. Actually, nobody calls the Poller.remove method anymore (poll will remove returned sockets automatically), so it must be a sync issue with add. I left the remove method in case Mladen changes his mind. I did some profiling yesterday, but didn't see anything interesting so far. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34647] - Tomcat cluster - Unable to receive message through TCP Channel
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=34647. 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=34647 --- Additional Comments From [EMAIL PROTECTED] 2005-05-04 10:56 --- (In reply to comment #1) The strack trace indicates that you have a principal (you are logged in) but the login name is null. Could you give us a small test case if you can create one and reproduce the error? Hi Filip... Have you any information about the bug reported? Thanks in advance, Anabel. -- 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/servlets DefaultServlet.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfclere 2005/05/04 00:04:30 Modified:catalina/src/share/org/apache/catalina/servlets DefaultServlet.java Log: When the file comes from a resource fileEncoding was not working. The default beahviour is unchanged: the file is send without a conversion. This kind of operation is extremely costly (will likely make fileEncoding a problematic option, as imagine doing it on a 1MB text file), and seems wrong: the purpose of the byte based sending is to send the resource unchanged. Yes, but if the text files are encoded in EBCDIC for example we will send EBCDIC to the browsers. 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
jean-frederic clere wrote: Yes, but if the text files are encoded in EBCDIC for example we will send EBCDIC to the browsers. Your change makes using the fileEncoding option extremely harmful. For straight file serving, we need to send the unchanged resource's bytes, so you need to properly encode them on your HD. This is not going to change. The purpose of fileEncoding is to be used when including static files using a request dispatcher, that's it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34693] - Tomcat infinite wait on noised network
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=34693. 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=34693 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2005-05-04 11:36 --- We need more information to reproduce this condition. Please, can you inform be about whats info do you need? For now I can tell to you that: - the same web-app works perfectly from another PC which is connected to the same server without noised cable - when the web-app hangs the other web-apps already works (but not the same-one) I traced network traffic and I have noticed that, with the sever-side TCP/IP connection state at CLOSE_WAIT, Tomcat use this connection to try to send HTTP-reply-fragment to client. -- 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/servlets DefaultServlet.java
Remy Maucherat wrote: jean-frederic clere wrote: Yes, but if the text files are encoded in EBCDIC for example we will send EBCDIC to the browsers. Your change makes using the fileEncoding option extremely harmful. For straight file serving, we need to send the unchanged resource's bytes, so you need to properly encode them on your HD. This is not going to change. but http://jakarta.apache.org/tomcat/tomcat-5.5-doc/default-servlet.html tells about fileEncoding: +++ File encoding to be used when reading static resources. [platform default] +++ My platform default is OSD_EBCDIC_DF04_1 I have no chances to convince the users to use UTF-8 for text files! and httpd (apache-1.3) it is serving those files correctly. What about converting the files when reading them? The purpose of fileEncoding is to be used when including static files using a request dispatcher, that's it. 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
jean-frederic clere wrote: Remy Maucherat wrote: but http://jakarta.apache.org/tomcat/tomcat-5.5-doc/default-servlet.html tells about fileEncoding: +++ File encoding to be used when reading static resources. [platform default] +++ My platform default is OSD_EBCDIC_DF04_1 I have no chances to convince the users to use UTF-8 for text files! and httpd (apache-1.3) it is serving those files correctly. Do you mean it has the same kind of ugly check for text files, and the same kind of file encoding option, and the same reencoding ? What about converting the files when reading them? No. I contend resources must be served as is in the default operation mode of DefaultServlet. If you disagree with that, you can use a filter, right ? 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/servlets DefaultServlet.java
Remy Maucherat wrote: jean-frederic clere wrote: Remy Maucherat wrote: but http://jakarta.apache.org/tomcat/tomcat-5.5-doc/default-servlet.html tells about fileEncoding: +++ File encoding to be used when reading static resources. [platform default] +++ My platform default is OSD_EBCDIC_DF04_1 I have no chances to convince the users to use UTF-8 for text files! and httpd (apache-1.3) it is serving those files correctly. Do you mean it has the same kind of ugly check for text files, and the same kind of file encoding option, and the same reencoding ? I won't tell it ugly, but yes the text file are in EBCDIC in the machine and converted to ASCII before beeing send to the browsers. What about converting the files when reading them? No. I contend resources must be served as is in the default operation mode of DefaultServlet. If you disagree with that, you can use a filter, right ? I will try to solve the problem with a filter. 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
jean-frederic clere wrote: I will try to solve the problem with a filter. You can simply call response.getWriter() in your filter if you determine the file needs to use fileEncoding. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Submission - Wild Card Aliases
George Sexton wrote: Let me see what I can do. So that I don't get a too bad reputation, here's an algorithm idea I thought about: - first, why use *.foo.com ? I'd say .foo.com is better (the algo will use it) - use a separate array for wildcard host names, where they are stored reversed (ex: moc.oof). - after doing the regular lookup, do a lookup in the wildcard host array (same as wildcard servlet mapping), but using the reversed host (findIgnoreCaseReverse or something) where you start with the last char - if the int returned corresponds to something which starts with (reversed) with your host, then it's the best match This way: - if there are no wildcard hosts, the cost is zero (the array will be empty) - you get nesting for free (ex: .private.foo.com and .foo.com - you don't need to add hosts to the main host array - you get to code funny algorithms during work hours, which IMO beats doing Struts form beans (YMMV) I still think the feature is borderline bloat, though ... :( Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Away until next monday
Hi, I'll be away (in Toulouse) until next Monday. I may or may not have access to email (I'll see there). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat performance patch (in development) to reduce concurrency...
Hi,
I wonder if anyone has any feedback on a performance change that I am
working on making.
One benefit of reducing concurrency in a server application is that a
small number of requests can complete more quickly than if they had to
compete against a large number of running threads for object locks (Java
or externally in a database).
I would like have a Tomcat configuration option to set the max number of
concurrent threads that can service user requests. You might configure
Tomcat to handle 800 http client connections but set the max concurrent
requests to 20 (perhaps higher if you have more CPUs). I like to refer
to the max concurrent requests setting as the throttle size (if there is
a better term, let me know).
I modified the Tomcat Thread.run code to use Doug Lea's semaphore
support but didn't expose a configuration option (haven't learned how to
do that yet). My basic change is to allow users to specify the max
number of concurrent servlet requests that can run. If an application
has a high level of concurrency, end users may get more consistent
response time with this change. If an application has a low level of
concurrency, my change doesn't help as their application only has a few
threads running concurrently anyway.
This also reduces resource use on other tiers. For example, if you are
supporting 500 users with a Tomcat instance, you don't need a database
connection pool size of 500, instead set the throttle size to 20 and
create a database connection pool size of 20.
Current status of the change:
1. org.apache.tomcat.util.threads.ThreadPool.CONCURRENT_THREADS is
hardcoded to a value of 18, should be a configurable option.
2. I hacked the build scripts to include Doug Lea's concurrent.jar but
probably didn't make these changes correctly. I could switch to using
the Java 1.5 implementation of the Concurrent package but we would still
need to do something for Java 1.4 compatibility.
Any suggestions on completing this enhancement are appreciated.
Please include my [EMAIL PROTECTED] email address in your response.
Thank you,
Scott Marlow --- Tomcat newbie
Index: ./jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
retrieving revision 1.30
diff -u -r1.30 ThreadPool.java
--- ./jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java 11 Dec 2004 03:52:56 - 1.30
+++ ./jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java 4 May 2005 13:32:57 -
@@ -20,6 +20,9 @@
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.tomcat.util.res.StringManager;
+import EDU.oswego.cs.dl.util.concurrent.FIFOSemaphore;
+import EDU.oswego.cs.dl.util.concurrent.NullSync;
+import EDU.oswego.cs.dl.util.concurrent.Sync;
/**
* A thread pool that is trying to copy the apache process management.
@@ -46,7 +49,8 @@
public static final int MAX_SPARE_THREADS = 50;
public static final int MIN_SPARE_THREADS = 4;
public static final int WORK_WAIT_TIMEOUT = 60*1000;
-
+public static final int UNLIMITED_CONCURRENT_THREADS = -1;
+public static final int CONCURRENT_THREADS = 18;
/*
* Where the threads are held.
*/
@@ -74,6 +78,17 @@
protected int maxSpareThreads;
/*
+ * number of threads that can run concurrently.
+ */
+protected int concurrentThreads;
+
+/*
+ * Doug Lea's Semaphore implementation used to
+ * control number of concurrent requests running.
+ */
+protected Sync concurrencySemaphore;
+
+/*
* Number of threads in the pool.
*/
protected int currentThreadCount;
@@ -123,6 +138,7 @@
currentThreadCount = 0;
currentThreadsBusy = 0;
stopThePool = false;
+concurrentThreads = CONCURRENT_THREADS;
}
@@ -143,6 +159,11 @@
adjustLimits();
+if(concurrentThreads 1)
+concurrencySemaphore = new NullSync();
+else
+concurrencySemaphore = new FIFOSemaphore(concurrentThreads);
+
pool = new ControlRunnable[maxThreads];
openThreads(minSpareThreads);
@@ -309,6 +330,10 @@
c.runIt(r);
}
+private Sync getConcurrencySemaphore() {
+return concurrencySemaphore;
+}
+
private ControlRunnable findControlRunnable() {
ControlRunnable c=null;
@@ -680,13 +705,24 @@
}
if (_shouldRun) {
-if (_toRun != null) {
-_toRun.runIt(t.getThreadData(p));
-} else if (toRunRunnable != null) {
-toRunRunnable.run();
-} else {
-
RE: Tomcat performance patch (in development) to reduce concurrency...
Hi, Repeatable benchmarks showing a significant improvement for some use case would be appreciated (certainly) and a prerequisite (probably) for addition into this relatively core part of Tomcat. I don't think this is much different than setting the current maxThreads (and min/max Spare threads) as opposed to acceptCount: one could set maxThreads to 20 and acceptCount to 500, for example. Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Scott Marlow [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 04, 2005 9:42 AM To: tomcat-dev@jakarta.apache.org Cc: [EMAIL PROTECTED] Subject: Tomcat performance patch (in development) to reduce concurrency... Hi, I wonder if anyone has any feedback on a performance change that I am working on making. One benefit of reducing concurrency in a server application is that a small number of requests can complete more quickly than if they had to compete against a large number of running threads for object locks (Java or externally in a database). I would like have a Tomcat configuration option to set the max number of concurrent threads that can service user requests. You might configure Tomcat to handle 800 http client connections but set the max concurrent requests to 20 (perhaps higher if you have more CPUs). I like to refer to the max concurrent requests setting as the throttle size (if there is a better term, let me know). I modified the Tomcat Thread.run code to use Doug Lea's semaphore support but didn't expose a configuration option (haven't learned how to do that yet). My basic change is to allow users to specify the max number of concurrent servlet requests that can run. If an application has a high level of concurrency, end users may get more consistent response time with this change. If an application has a low level of concurrency, my change doesn't help as their application only has a few threads running concurrently anyway. This also reduces resource use on other tiers. For example, if you are supporting 500 users with a Tomcat instance, you don't need a database connection pool size of 500, instead set the throttle size to 20 and create a database connection pool size of 20. Current status of the change: 1. org.apache.tomcat.util.threads.ThreadPool.CONCURRENT_THREADS is hardcoded to a value of 18, should be a configurable option. 2. I hacked the build scripts to include Doug Lea's concurrent.jar but probably didn't make these changes correctly. I could switch to using the Java 1.5 implementation of the Concurrent package but we would still need to do something for Java 1.4 compatibility. Any suggestions on completing this enhancement are appreciated. Please include my [EMAIL PROTECTED] email address in your response. Thank you, Scott Marlow --- Tomcat newbie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Scott Marlow wrote: Hi, I wonder if anyone has any feedback on a performance change that I am working on making. One benefit of reducing concurrency in a server application is that a small number of requests can complete more quickly than if they had to compete against a large number of running threads for object locks (Java or externally in a database). I would like have a Tomcat configuration option to set the max number of concurrent threads that can service user requests. You might configure Tomcat to handle 800 http client connections but set the max concurrent requests to 20 (perhaps higher if you have more CPUs). I like to refer to the max concurrent requests setting as the throttle size (if there is a better term, let me know). I modified the Tomcat Thread.run code to use Doug Lea's semaphore support but didn't expose a configuration option (haven't learned how to do that yet). My basic change is to allow users to specify the max number of concurrent servlet requests that can run. If an application has a high level of concurrency, end users may get more consistent response time with this change. If an application has a low level of concurrency, my change doesn't help as their application only has a few threads running concurrently anyway. This also reduces resource use on other tiers. For example, if you are supporting 500 users with a Tomcat instance, you don't need a database connection pool size of 500, instead set the throttle size to 20 and create a database connection pool size of 20. Current status of the change: 1. org.apache.tomcat.util.threads.ThreadPool.CONCURRENT_THREADS is hardcoded to a value of 18, should be a configurable option. 2. I hacked the build scripts to include Doug Lea's concurrent.jar but probably didn't make these changes correctly. I could switch to using the Java 1.5 implementation of the Concurrent package but we would still need to do something for Java 1.4 compatibility. Any suggestions on completing this enhancement are appreciated. Please include my [EMAIL PROTECTED] email address in your response. I looked at this yesterday, and while it is a cool hack, it is not that useful anymore (and we're also not going to use the concurrent utilities in Tomcat, so it's not really an option before we require Java 5). The main issue is that due to the fact keepalive is done in blocking mode, actual concurrency in the servlet container is unpredictable (the amount of processing threads - maxThreads - will usually be a lot higher than the actual expected concurrency - let's say 100 per CPU). If that issue is solved (we're trying to see if APR is a good solution for it), then the problem goes away. Your patch is basically a much nicer implementation of maxThreads (assuming it doesn't reduce performance) which would be useful for the regular HTTP connector, so it's cool, but not worth it. Overall, I think the way maxThreads is done in the APR connector is the easiest (if the amount of workers is too high, wait a bit without accepting anything). However, reading the text of the message, you don't seem to realize that a lot of the threads which would actually be doing processing are just blocking for keepalive (hence not doing anything useful; maybe you don't see it in your test). Anyway, congratulations for understanding that ThreadPool code (I stopped using it for new code, since I think it has some limitations and is too complex). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Creating and deploying a StandardContex from a Servlet
Hi, I've tried asking this question on the tomcat-user list with no success. Since it is related to the Tomcat API I hope someone here could give me some tips. What I basically need to do is to create a customized manager webapplication. It will display all loaded webapplication where the names have a specific prefix. Also, it will be able to undeploy all of these webapps and then deploy all webapps from a specific path. I have a Servlet implementing ContainerServlet. Using this I've manage to retrieve all webapps from the current Host (myHost.findChildren()). I've also manage to create StandardContext instances, set the properties I thought were necessary and added them to the Host (myHost.addChild()). This doesn't work very well however, since the new webapps seem to be deployed but cannot start. Neither is it possible to remove them through the Manager webapp. So my question is; what is the proper way for creating a new StandardContext, setting the right properties, deploy and start it? Right now I'm doing the following: --- theContext = new StandardContext(); theContext.setDisplayName(thePath); theContext.setDocBase(myBaseDir + thePath); theContext.setName(thePath); theContext.setPath(thePath); myHost.addChild(theContext); theContext.start(); --- I know this list is for development of Tomcat, but I guess this question is close enough. :) regards, Erik
Re: Tomcat performance patch (in development) to reduce concurrency...
Scott Marlow wrote: Hi, I wonder if anyone has any feedback on a performance change that I am working on making. Can you compare the performance of you code with the standard implementation when the concurrency is lower then maxThreads value? I see no point to make patches that will deal with cases presuming that the concurrency is always higher then the actual number of worker threads available. IMHO this is a bad design approach for the http applications, and NIO performance is a proof of that. It might help in cases where you have a very very slow clients. In any other case the thread context switching will kill the performance thought. Further more I don't see how can you avoid keep-alive connection problems without using a thread-per-connection model. The point is that with 100 keep-alive connections you will still have 100 busy threads. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Mladen Turk wrote: Scott Marlow wrote: Hi, I wonder if anyone has any feedback on a performance change that I am working on making. Can you compare the performance of you code with the standard implementation when the concurrency is lower then maxThreads value? I see no point to make patches that will deal with cases presuming that the concurrency is always higher then the actual number of worker threads available. IMHO this is a bad design approach for the http applications, and NIO performance is a proof of that. It might help in cases where you have a very very slow clients. In any other case the thread context switching will kill the performance thought. Further more I don't see how can you avoid keep-alive connection problems without using a thread-per-connection model. The point is that with 100 keep-alive connections you will still have 100 busy threads. Why ? 100 keep alive connections doesn't mean 100 active requests, in real servers there are many 'keep alive' connections that are just waiting for the next request. In all servers I know, concurrency was higher than the configured number of workers - at peak time, at least, where performance matters. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Remy Maucherat wrote: I looked at this yesterday, and while it is a cool hack, it is not that useful anymore (and we're also not going to use the concurrent utilities in Tomcat, so it's not really an option before we require Java 5). The main issue is that due to the fact keepalive is done in blocking mode, actual concurrency in the servlet container is unpredictable (the amount of processing threads - maxThreads - will usually be a lot higher than the actual expected concurrency - let's say 100 per CPU). If that issue is solved (we're trying to see if APR is a good solution for it), then the problem goes away. I'm still trying to understand the APR connector, but from what I see it is still mapping one socket ( 'keep alive' connection ) per thread. That's how it allways worked - but it's not necesarily the best solution. The only thing that is required is to have a thread per active request - the sleepy keep alives don't need thread ( that could be implemented using select in the apr, or nio in java ) Your patch is basically a much nicer implementation of maxThreads (assuming it doesn't reduce performance) which would be useful for the regular HTTP connector, so it's cool, but not worth it. Overall, I think the way maxThreads is done in the APR connector is the easiest (if the amount of workers is too high, wait a bit without accepting anything). That's a tricky issue :-) In some cases ( like load balancing ) not accepting is the right solution, but in other cases droping connections is not what people want ( in particular if most of the threads are just waiting on keep alives ). ( sorry if I missed some details in the new implementation :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Costin Manolache wrote: Further more I don't see how can you avoid keep-alive connection problems without using a thread-per-connection model. The point is that with 100 keep-alive connections you will still have 100 busy threads. Why ? 100 keep alive connections doesn't mean 100 active requests, in real servers there are many 'keep alive' connections that are just waiting for the next request. Where are they waiting if in blocking mode? IIRC each is inside a separate thread. In all servers I know, concurrency was higher than the configured number of workers - at peak time, at least, where performance matters. Sure, but this is for accepting new connections, right? Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Costin Manolache wrote: I'm still trying to understand the APR connector, but from what I see it is still mapping one socket ( 'keep alive' connection ) per thread. No it doesn't. If the connection is keep-alive, and there is no activity for 100ms, the socket is put in the poller, and that thread is freed. When the next data on that socket arrives, the socket is signaled and passed to the thread pool. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Mladen Turk wrote: Costin Manolache wrote: I'm still trying to understand the APR connector, but from what I see it is still mapping one socket ( 'keep alive' connection ) per thread. No it doesn't. If the connection is keep-alive, and there is no activity for 100ms, the socket is put in the poller, and that thread is freed. When the next data on that socket arrives, the socket is signaled and passed to the thread pool. Mladen. Sorry, I missed that. So we can have as many 'keep alive' idle as we want - only those active are taking threads ? Which file implements this ( the 100ms timeout and poller ) ? I assume this is only done in the APR connector, or is it implemented in java as well ( nio ) ? . Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code Submission - Wild Card Aliases
Rémy, I'll look at those. So far, I re-wrote the algorithm, and I've got it improved. The old algorithm (5.5.9) takes 8772 ms on a P3 600 ( My earlier timed reports were approximate but relative). My current version of the algorithm taks 7383 ms. This is for the million iterations with about 15 hosts, and 6 or so contexts. The improvement for 1 million iterations is 1389 milli-seconds, or about 15%. I suspect most of the remaining time is in the context lookup now. The current algorithm is using a parallel int array of hash codes which it uses to quickly find (using Arrays.binarySearch(int[],int)) the array element, and then it does a string comparison using the CharChunk.equalsIgnoreCase() method for the final comparison. I have handled the possibility of collision in the hash usage, so that is not a concern. I believe the slow down in my initial attempt was not caused by the HashMap, but caused by the call to CharChunk.toString() and the corresponding toLowerCase() to get the key. As far as feature bloat goes, that's relative. I look at some of the current features and think That must be a one in a thousand installations thing An example that comes to mind is the proxying support. It comes down to what the person using it is doing. In my case, I'm hosting 40 virtual hosts in one instance, on one machine (a P3 600). In the near future, I'm probably going to be adding 5-10 virtual hosts per month. I'm hoping that I'll be able to scale to 200 virtual hosts per (newer, faster) server. The feature in my software that I need wild card aliases for is this: We have a calendar application. Large customers with many calendars are not comfortable with the sheer number of calendars that show to the public, or they want to have one set of calendars show to one group of public users, while another set of calendars show to another set of public users. Our solution was to select the public calendars based on the virtual host name of the request. In this way, training.foo.com would have one set of calendars, while marketing_events.foo.com can have a different set of public calendars. Without wild-card aliases, I have to manually add each alias they want to use to tomcat, and re-start the engine. This would be painful for larger customers. Out of my 40 current customers, about 4 are going to immediately start using the virtual host feature in my software. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 04, 2005 5:45 AM To: Tomcat Developers List Subject: Re: Code Submission - Wild Card Aliases George Sexton wrote: Let me see what I can do. So that I don't get a too bad reputation, here's an algorithm idea I thought about: - first, why use *.foo.com ? I'd say .foo.com is better (the algo will use it) - use a separate array for wildcard host names, where they are stored reversed (ex: moc.oof). - after doing the regular lookup, do a lookup in the wildcard host array (same as wildcard servlet mapping), but using the reversed host (findIgnoreCaseReverse or something) where you start with the last char - if the int returned corresponds to something which starts with (reversed) with your host, then it's the best match This way: - if there are no wildcard hosts, the cost is zero (the array will be empty) - you get nesting for free (ex: .private.foo.com and .foo.com - you don't need to add hosts to the main host array - you get to code funny algorithms during work hours, which IMO beats doing Struts form beans (YMMV) I still think the feature is borderline bloat, though ... :( 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 performance patch (in development) to reduce concurrency...
Costin Manolache wrote: No it doesn't. If the connection is keep-alive, and there is no activity for 100ms, the socket is put in the poller, and that thread is freed. When the next data on that socket arrives, the socket is signaled and passed to the thread pool. Mladen. Sorry, I missed that. So we can have as many 'keep alive' idle as we want - only those active are taking threads ? Yes. You will need APR HEAD if using WIN32 and wish more the 64 of them. On most other platforms, the limit is controlled by ulimit. Which file implements this ( the 100ms timeout and poller ) ? When the active thread finishes the response that is going to be the keep-alive it reads with timeout for 100ms. Thus if the next keep-alive request comes within 100ms it is handled immediately. If not it is passed to the poller. I assume this is only done in the APR connector, or is it implemented in java as well ( nio ) ? . jakarta-tomcat-connectors/jni We have APR and thin native JNI glue code, basically dealing with apr types and pointers. Regards, Mladen. - 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/servlets DefaultServlet.java
[EMAIL PROTECTED] wrote:
jfclere 2005/05/04 00:04:30
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
Log:
When the file comes from a resource fileEncoding was not working.
The default beahviour is unchanged: the file is send without a conversion.
if (cacheEntry.resource != null) {
byte buffer[] = cacheEntry.resource.getContent();
if (buffer != null) {
+if (fileEncoding != null
+cacheEntry.attributes.getMimeType()!=null
+cacheEntry.attributes.getMimeType().equals(text/html))
{
+/* the binary have to be converted from fileEncoding
to UTF-8 */
+try {
+String str = new String(buffer, fileEncoding);
+buffer = str.getBytes(UTF-8);
+} catch (Exception e) {
+}
+}
ostream.write(buffer, 0, buffer.length);
return;
So, can you revert the patch ? I think that's what we more or less
agreed on, right ?
Forcing the use of a writer using a getWriter call would likely be more
efficient (much less GC hungry at least).
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Costin Manolache wrote: Which file implements this ( the 100ms timeout and poller ) ? Poller is inside: /jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/AprEndpoint.java 100ms timeout and passing to poller is in: /jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java Rest is inside: /jakarta-tomcat-connectors/jni Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Submission - Wild Card Aliases
George Sexton wrote: Rémy, I'll look at those. So far, I re-wrote the algorithm, and I've got it improved. The old algorithm (5.5.9) takes 8772 ms on a P3 600 ( My earlier timed reports were approximate but relative). My current version of the algorithm taks 7383 ms. This is for the million iterations with about 15 hosts, and 6 or so contexts. The improvement for 1 million iterations is 1389 milli-seconds, or about 15%. I suspect most of the remaining time is in the context lookup now. The current algorithm is using a parallel int array of hash codes which it uses to quickly find (using Arrays.binarySearch(int[],int)) the array element, and then it does a string comparison using the CharChunk.equalsIgnoreCase() method for the final comparison. I have handled the possibility of collision in the hash usage, so that is not a concern. I believe the slow down in my initial attempt was not caused by the HashMap, but caused by the call to CharChunk.toString() and the corresponding toLowerCase() to get the key. As far as feature bloat goes, that's relative. I look at some of the current features and think That must be a one in a thousand installations thing An example that comes to mind is the proxying support. It comes down to what the person using it is doing. In my case, I'm hosting 40 virtual hosts in one instance, on one machine (a P3 600). In the near future, I'm probably going to be adding 5-10 virtual hosts per month. I'm hoping that I'll be able to scale to 200 virtual hosts per (newer, faster) server. The feature in my software that I need wild card aliases for is this: We have a calendar application. Large customers with many calendars are not comfortable with the sheer number of calendars that show to the public, or they want to have one set of calendars show to one group of public users, while another set of calendars show to another set of public users. Our solution was to select the public calendars based on the virtual host name of the request. In this way, training.foo.com would have one set of calendars, while marketing_events.foo.com can have a different set of public calendars. Without wild-card aliases, I have to manually add each alias they want to use to tomcat, and re-start the engine. This would be painful for larger customers. Out of my 40 current customers, about 4 are going to immediately start using the virtual host feature in my software. As I said, I do not want it. If you are not willing to make the necessary revisions to your algorithm, I will not withdraw my -1. I maintain that this is almost bloat: you can obviously make use cases for vitually anything, which will be of no value for 99.9% of users. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Costin Manolache wrote:
Mladen Turk wrote:
Costin Manolache wrote:
I'm still trying to understand the APR connector, but from what I see
it is still mapping one socket ( 'keep alive' connection ) per thread.
No it doesn't. If the connection is keep-alive, and there is no activity
for 100ms, the socket is put in the poller, and that thread is freed.
When the next data on that socket arrives, the socket is signaled and
passed to the thread pool.
Sorry, I missed that. So we can have as many 'keep alive' idle as we
want - only those active are taking threads ? Which file implements this
( the 100ms timeout and poller ) ? I assume this is only done in the APR
connector, or is it implemented in java as well ( nio ) ? .
What I like is that it does it *and* it still is extremely similar to
the regular blocking HTTP connector.
From Http11AprProcessor.process:
if (!inputBuffer.parseRequestLine()) {
// This means that no data is available right now
// (long keepalive), so that the processor should
be recycled
// and the method should return true
rp.setStage(org.apache.coyote.Constants.STAGE_ENDED);
openSocket = true;
// Add the socket to the poller
endpoint.getPoller().add(socket, pool);
break;
}
The 100ms before going to the poller is to optimize a little the
pipelining case (assuming it does optimize something - I don't know).
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
How to redirect all ports to use SSL?
I want all my Tomcat requests to go through SSL. I want the URLs to look like https://this/ and not https://this:8443 I setup tomcat, and got ssl working on 8443. But I cannot redirect port 80 to 8443. I keep getting 'access denied'. Is there a way in Tomcat to redirect all port 80 requests to SSL(8443)? I know you can do it the other way around 8443 - 80. I'm just running standalone Tomcat, no Apache. advTHANKSance! ...Don...
Re: How to redirect all ports to use SSL?
This is a question for tomcat-user, not tomcat-dev Mark Donny R Rota wrote: I want all my Tomcat requests to go through SSL. I want the URLs to look like https://this/ and not https://this:8443 I setup tomcat, and got ssl working on 8443. But I cannot redirect port 80 to 8443. I keep getting 'access denied'. Is there a way in Tomcat to redirect all port 80 requests to SSL(8443)? I know you can do it the other way around 8443 - 80. I'm just running standalone Tomcat, no Apache. advTHANKSance! ...Don... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34746] New: - Specifying an explict jar file pathname in shared.loader property fails
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=34746. 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=34746 Summary: Specifying an explict jar file pathname in shared.loader property fails Product: Tomcat 5 Version: 5.0.30 Platform: Sun OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] When specifying an explicit jat file path name in the shared.loader property of catalina.properties file, the jar file is not loaded. The problem occurs between the Bootstrap.createClassLoader method and the StandardClassLoader.addRepositoryInternal method. In the form method, a File instance is created in which the path name has a File.separator appended. This occurs only if the resource path ends with .jar and does not end with *.jar. In the latter method, the pathname in the File instance passed in the unpacked parameter is checked to see if it ends with the / character. If so, it is not opened and its manifest is not added to the opened Jars. To workaround, simply make the explicit jar file pathname a URL; that is, prefix its path with file: in the shared.loader property in catalina.properties. -- 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: Code Submission - Wild Card Aliases
You should read my message more carefully. I re-wrote it. It's 15% faster than the current 5.5.9 code. Elapsed time drops from 8772 ms for the stock 5.5.9 code to 7383ms for the revised code. You know, I bit my lip and re-wrote the algorithm, even though I think it's a case of pursuing performance mindlessly at the expense of maintainability. If anyone thinks I'm exagerating this, look at the code. There are re-implementations of binary search algorithms and case-insensitive comparisons. I spent several hours fine-tuning the code to yield a really, measurable performance increase. I am more than a little personally offended by your cavalier and autocratic attitude. You didn't even bother to read the first few paragraphs of my message. Yes, you can make use cases for anything, but a real thorn in my side as a commercial software developer using servlets is that hosting companies won't run servlet engines. I think that the things I am running into are the same problems any commercial hoster is going to run into. This is the same circle we went into a year ago when I griped that the management application was host oriented, and required a context installed in every virtual host. Just because someone want to do something with a product that you don't does not mean their reasons aren't valid, or that it's fair to use emotionally charged and dismissive terms to describe their position. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 04, 2005 11:45 AM To: Tomcat Developers List Subject: Re: Code Submission - Wild Card Aliases George Sexton wrote: Rémy, I'll look at those. So far, I re-wrote the algorithm, and I've got it improved. The old algorithm (5.5.9) takes 8772 ms on a P3 600 ( My earlier timed reports were approximate but relative). My current version of the algorithm taks 7383 ms. This is for the million iterations with about 15 hosts, and 6 or so contexts. The improvement for 1 million iterations is 1389 milli-seconds, or about 15%. I suspect most of the remaining time is in the context lookup now. The current algorithm is using a parallel int array of hash codes which it uses to quickly find (using Arrays.binarySearch(int[],int)) the array element, and then it does a string comparison using the CharChunk.equalsIgnoreCase() method for the final comparison. I have handled the possibility of collision in the hash usage, so that is not a concern. I believe the slow down in my initial attempt was not caused by the HashMap, but caused by the call to CharChunk.toString() and the corresponding toLowerCase() to get the key. As far as feature bloat goes, that's relative. I look at some of the current features and think That must be a one in a thousand installations thing An example that comes to mind is the proxying support. It comes down to what the person using it is doing. In my case, I'm hosting 40 virtual hosts in one instance, on one machine (a P3 600). In the near future, I'm probably going to be adding 5-10 virtual hosts per month. I'm hoping that I'll be able to scale to 200 virtual hosts per (newer, faster) server. The feature in my software that I need wild card aliases for is this: We have a calendar application. Large customers with many calendars are not comfortable with the sheer number of calendars that show to the public, or they want to have one set of calendars show to one group of public users, while another set of calendars show to another set of public users. Our solution was to select the public calendars based on the virtual host name of the request. In this way, training.foo.com would have one set of calendars, while marketing_events.foo.com can have a different set of public calendars. Without wild-card aliases, I have to manually add each alias they want to use to tomcat, and re-start the engine. This would be painful for larger customers. Out of my 40 current customers, about 4 are going to immediately start using the virtual host feature in my software. As I said, I do not want it. If you are not willing to make the necessary revisions to your algorithm, I will not withdraw my -1. I maintain that this is almost bloat: you can obviously make use cases for vitually anything, which will be of no value for 99.9% of users. 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: Code Submission - Wild Card Aliases
George Sexton wrote: You should read my message more carefully. I re-wrote it. It's 15% faster than the current 5.5.9 code. Elapsed time drops from 8772 ms for the stock 5.5.9 code to 7383ms for the revised code. You know, I bit my lip and re-wrote the algorithm, even though I think it's a case of pursuing performance mindlessly at the expense of maintainability. If anyone thinks I'm exagerating this, look at the code. There are re-implementations of binary search algorithms and case-insensitive comparisons. I spent several hours fine-tuning the code to yield a really, measurable performance increase. I am more than a little personally offended by your cavalier and autocratic attitude. You didn't even bother to read the first few paragraphs of my message. Yes, you can make use cases for anything, but a real thorn in my side as a commercial software developer using servlets is that hosting companies won't run servlet engines. I think that the things I am running into are the same problems any commercial hoster is going to run into. This is the same circle we went into a year ago when I griped that the management application was host oriented, and required a context installed in every virtual host. Just because someone want to do something with a product that you don't does not mean their reasons aren't valid, or that it's fair to use emotionally charged and dismissive terms to describe their position. If you want me to be less dismissive, and you want to touch to critical code, you'll have to become a committer first or submit obviously good code. This means caring more about improving things than adding the one feature you care about, and which seems questionable. The original code you submitted looks quite bad so I don't trust your measurements at all, sorry. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Michael Bünermann/HBF/Minden/kampa/DE ist außer Haus.
Ich werde ab 04.05.2005 nicht im Büro sein. Ich kehre zurück am 09.05.2005. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. In dringenden Fällen wenden Sie sich bitte Herrn Bagehorn ([EMAIL PROTECTED]). Herr Bagehorn hat die Rufnummer 0571/93425-80) Am Montag und Dienstag, den 02.05- 03.05.2005 erreichen Sie mich auch über die Funk-Rufnummer: 0171/99 33 525.
DO NOT REPLY [Bug 31794] - Custom HTTP 400 error page
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=31794. 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=31794 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2005-05-05 01:24 --- using 5.0.27, it still has the bug. The Coyote http11 adapter catches the bad uri syntax and doesn't redirect to the error page. Example url: http://host/hoho% error-page error-code400/error-code location/WEB-INF/pages/servletErrors.jsp/location /error-page -- 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 34513] - jsp exception handling
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=34513. 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=34513 --- Additional Comments From [EMAIL PROTECTED] 2005-05-05 02:25 --- Maybe some misunderstanding. What I feel wierd about is not the JspWriter's exception(caused by the commited response) itself. I think there's something could be done under such a jsp exception(eg. output to the tomcat log). I think that may be helpful because that gives the developer some hint about the error happened in his coding. -- 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 34749] New: - jsessionid dropped on trailing slash (/) redirect
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=34749. 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=34749 Summary: jsessionid dropped on trailing slash (/) redirect Product: Tomcat 5 Version: 5.0.30 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Connector:Coyote AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] When CoyoteAdapter forces a redirect from, e.g., /someDir to /someDir/ it omits the jsessionid from the URL. This prevents Filters from using the session after the redirect. To reproduce: 1. Turn off cookies by adding DefaultContext cookies=false/ to server.xml. 2. Start Tomcat and browse to the session example: http://localhost:8080/servlets-examples/servlet/SessionExample 3. Click on the URL encoded link, e.g.: http://localhost:8080/servlets-examples/servlet/SessionExample;jsessionid=B191701A64C8AA13956E21B3C6D801AA?dataname=foodatavalue=bar 4. Edit the URL changing servlet/SessionExample to images/ and press Enter: http://localhost:8080/servlets-examples/images/;jsessionid=B191701A64C8AA13956E21B3C6D801AA?dataname=foodatavalue=bar 5. Edit the URL deleting the / before the ; and press Enter: http://localhost:8080/servlets-examples/images;jsessionid=B191701A64C8AA13956E21B3C6D801AA?dataname=foodatavalue=bar 6. Observe that the redirected URL is missing the jsessionid: http://localhost:8080/servlets-examples/images/?dataname=foodatavalue=bar (This bug can also be reproduced without the query parameters.) -- 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 33106] - SSI Processing Enhancements (patch provided)
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=33106. 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=33106 --- Additional Comments From [EMAIL PROTECTED] 2005-05-05 06:05 --- Looking in the web cvs view at http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/ I don't see the SSIFilter. Am I missing something? Or does that lag a little bit behind the actual CVS checkins? -- 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]
