RE: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper HostMap.java Mapper.java
-Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Saturday, June 04, 2005 11:30 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/htt p/mapper HostMap.java Mapper.java And the usefulness of that is non existent as well. What's the purpose of adding hosts if they are all the same ? The reasoning as I explained in my very lengthy message justifying the patch is to allow the application to have different behaviors based on the virtual host name, without having to re-configure tomcat. -1 vote for this feature. Rémy George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper HostMap.java Mapper.java
-Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Saturday, June 04, 2005 1:27 PM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/htt p/mapper HostMap.java Mapper.java - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Saturday, June 04, 2005 10:29 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/htt p/mapper HostMap.java Mapper.java Peter Rossbach wrote: Hey Remy, For usefull feature I don't give up :-) Fine, I'll just revert your patch then ;) The default of host alias matching is off. The current implementation is little bit fast then the old one. (Great) Every user of this feature can limit the dynamic host addition with Connector port=8080 allowedAliasMatches=10 / The issue is that this mechanism is bad, period. I have to agree with Remy on this. The issue is that the code is just plain bad :(. So I'm going to add my -1 to the patch until the There's no justification here. Explain why you think the code is bad it's actually a hell of a lot cleaner and easier to follow than the original code, and it's 15% faster. What exactly are your criteria for measuring goodness. mechanism is cleaned up. In fact, I'd have -1ed it just for the import com.sun. line alone. I don't know what you are looking at. My submission had NO com.sun.xxx class imports. Perhaps you missed the thread where I said I rewrote it? http://www.mhsoftware.com/~gsexton/HostMap.java http://www.mhsoftware.com/~gsexton/Mapper.java If you are going to -1 some code, you should at least look at it. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code Submission - Wild Card Aliases
OK, here is what I believe is the final version of the Mapper code with support for wildcard matching. The new code is approximately 14.7% faster, executing the 1,000,000 iteration test loop in 7480 ms versus 8772.5 ms for the original code, a difference of 1292.5 ms. Times were computed by executing the main() function 10 times, and recording the results. The median value was then calculated and used for reporting. For those interested, the times for the tests are below. Here are the files: HostMap.java - New File to act as a container for hosts. It contains searching methods to find hosts. http://www.mhsoftware.com/~gsexton/HostMap.java Mapper.diff - Diff between 5.5.9 mapper and the current one. Because of the abstraction of the host mapping into a new class it's not super useful, but included for completeness. http://www.mhsoftware.com/~gsexton/Mapper.diff Mapper.java - Complete, modified Mapper.java file. http://www.mhsoftware.com/~gsexton/Mapper.java Harness_output.diff - Difference between the test harness output using the 5.5.9 code, and the modified code. http://www.mhsoftware.com/~gsexton/harness_output.diff Once I sort out the correct method of setting the default # of Alias Matches, I will submit the complete set as a diff. Unless someone else want to do the parameter setting. Right now the default # of alias matches is hard-wired to 16. Some people have asked me to integrate the test harness into a Junit testing module. Unfortunately, I don't have any experience w/ Junit, so I don't think I would be a good candidate for this. There's one final thing. During previous discussions, it was kind of hinted I should put the alias match limiting in the Connector. It seems kind of ugly since this seems to apply at the host or alias level. Does anyone have thoughts on this? For testing purposes, a P3 600 Mhz running SUSE Linux 9.2, w/ JDK 1.4.2_06-b03 was used. New Code 7477ms 7641ms 7692ms 7394ms 7395ms 7475ms 7527ms 7482ms 7480ms 7480ms Median: 7480ms 5.5.9 Mapper w/ New Test Harness 8561ms 8560ms 8771ms 8774ms 8771ms 8767ms 8860ms 8775ms 8775ms 8782ms Median: 8772.5ms George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Peter Rossbach [mailto:[EMAIL PROTECTED] Sent: Thursday, May 05, 2005 8:40 AM To: Tomcat Developers List Subject: Re: Code Submission - Wild Card Aliases Great news, can you post your new code that we can test it also? Many thanks Peter George Sexton schrieb: The measurement was calculated by taking the median reading of 10 consecutive executions. Just for your edification they were: New Code: 7373ms 7395ms 7383ms 7370ms 7384ms 7385ms 7395ms 7376ms 7378ms 7393ms Median: 7383.5ms Old code: 8561ms 8560ms 8771ms 8774ms 8771ms 8767ms 8860ms 8775ms 8775ms 8782ms Median: 8772.5ms Difference: 1389ms ~ 15.8% improved My mistake for not wanting to bore the list with minutiae. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code Submission - Wild Card Aliases
That's your opinion. What about the completely revised and improved test harness that I wrote to ensure that your critical code was working the same way. Doesn't that indicate some care and seriousness of purpose? 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 1:41 PM To: Tomcat Developers List Subject: Re: Code Submission - Wild Card Aliases George Sexton wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code Submission - Wild Card Aliases
The measurement was calculated by taking the median reading of 10 consecutive executions. Just for your edification they were: New Code: 7373ms 7395ms 7383ms 7370ms 7384ms 7385ms 7395ms 7376ms 7378ms 7393ms Median: 7383.5ms Old code: 8561ms 8560ms 8771ms 8774ms 8771ms 8767ms 8860ms 8775ms 8775ms 8782ms Median: 8772.5ms Difference: 1389ms ~ 15.8% improved My mistake for not wanting to bore the list with minutiae. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- 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] - 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: 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
Does anyone care about sort order? The order that the host names come out in
the proposed code is going to be very random. Part of the reasoning behind
getting the keys was to ensure the elements came back sorted in order.
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-Original Message-
From: Peter Rossbach [mailto:[EMAIL PROTECTED]
Sent: Monday, May 02, 2005 10:28 PM
To: Tomcat Developers List
Subject: Re: Code Submission - Wild Card Aliases
Hey Geroge,
I review the mapper patch. Cool!
I think getHosts is a little bit strange:
What you think about this:
public String[] getHosts() {
Host[] hosts ;
synchronized(this) {
hosts=new Host[hmHosts.size()];
hosts=(Host[])hmHosts.values().toArray(hosts);
}
String[] hostNames=new String[hmHosts.size()];
for ( int i = 0; i hosts.length; i++ ) {
hostNames[i] = hosts[i].name;
}
return hostNames ;
}
I thing sync is needed. I miss that also at orginal mapper. The host
values get array you also coded at getContextNames().
Can we change getHost to be protected.
Have you wrote junit testcases for the Mapper ?
Please, extract the testcode. I hate those test code inside
production code :-)
I find you patch very usefull!
Thanks
Peter
George Sexton schrieb:
I have completed the coding in o.a.t.u.http.mapper.Mapper to
implement
wild-card aliases.
If a request for a host is made, and that host is not found,
the code tests
the host and aliases list and looks for wild-cards.
So, a host name of www.mydomain.com would match an alias of
*.mydomain.com.
This additional level of testing is only done if the the
presented host name
is not found in the standard host list. Once a host is found
via wild-card,
it is added to the standard host list. Subsequent requests
for that host
name will find it via the standard search mechanism.
As part of the conversion, I re-worked the test harness code
and expanded it
to be a lot more complete. The output of the new test
harness with the
unmodified Mapper code matches identically the output of the modified
mapper. IOW, I'm 99% confident that the behavior of the
Mapper matches the
old Mapper.
The time differential between the two runs is around 500ms
over 1 million
iterations. I.E. the original code runs in 8000 ms for 1
million iterations
of the testing code, while the new code takes 8500ms. The
new code adds
approximately 0.05 % to the time for a lookup.
I am running the modified mapper code with 5.5.9 on an
installation that has
40 hosts configured and it seems to be working correctly.
I'd really appreciate it if a committer would get this added
to the source
tree.
The complete modified Mapper.java file can be downloaded from:
http://www.mhsoftware.com/~gsexton/Mapper.java
If a decision is made to reject this patch, I'd appreciate
knowing why. If
there's something wrong from a coding or style perspective,
I'd be happy to
fix things.
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code Submission - Wild Card Aliases
0.05% lower is hardly a sufficient reason to reject this. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 8:04 AM To: Tomcat Developers List Subject: Re: Code Submission - Wild Card Aliases George Sexton wrote: I have completed the coding in o.a.t.u.http.mapper.Mapper to implement wild-card aliases. If a request for a host is made, and that host is not found, the code tests the host and aliases list and looks for wild-cards. So, a host name of www.mydomain.com would match an alias of *.mydomain.com. This additional level of testing is only done if the the presented host name is not found in the standard host list. Once a host is found via wild-card, it is added to the standard host list. Subsequent requests for that host name will find it via the standard search mechanism. As part of the conversion, I re-worked the test harness code and expanded it to be a lot more complete. The output of the new test harness with the unmodified Mapper code matches identically the output of the modified mapper. IOW, I'm 99% confident that the behavior of the Mapper matches the old Mapper. The time differential between the two runs is around 500ms over 1 million iterations. I.E. the original code runs in 8000 ms for 1 million iterations of the testing code, while the new code takes 8500ms. The new code adds approximately 0.05 % to the time for a lookup. I am running the modified mapper code with 5.5.9 on an installation that has 40 hosts configured and it seems to be working correctly. I'd really appreciate it if a committer would get this added to the source tree. The complete modified Mapper.java file can be downloaded from: http://www.mhsoftware.com/~gsexton/Mapper.java If a decision is made to reject this patch, I'd appreciate knowing why. If there's something wrong from a coding or style perspective, I'd be happy to fix things. -1 for lower performance and questionable use case. (I didn't get the patch, but I don't really wish to) 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
Oops, my bad. In actuality, 1 million requests is taking 8,000,000 microseconds on my computer, or 8 microseconds per mapper call. The modification adds 0.5 microseconds to the call. I think given hideous monstrosities like Struts that are layered on top of Tomcat, 0.5 microseconds per call is hardly worth caring about. The real reason the code is slower is because I simplified the list management. The list management code is extra-ordinarily difficult to follow. It is filled with a lot of special case items that required a deep understanding of the whole in order to modify it. An example of this is the find routine that returns the position of the item, or the insert position. This leaves the code filled with oddities like getting back a result, and then doing a case-insensitive string comparison to see if found really found the right thing. If the mapper were modified very often, it would be a major source of problems. In general I favor maintainability and correctness over raw speed. The DOS issue raised by Jin Yu could be a real issue. I'll think it over some more. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 8:04 AM To: Tomcat Developers List Subject: Re: Code Submission - Wild Card Aliases George Sexton wrote: I have completed the coding in o.a.t.u.http.mapper.Mapper to implement wild-card aliases. If a request for a host is made, and that host is not found, the code tests the host and aliases list and looks for wild-cards. So, a host name of www.mydomain.com would match an alias of *.mydomain.com. This additional level of testing is only done if the the presented host name is not found in the standard host list. Once a host is found via wild-card, it is added to the standard host list. Subsequent requests for that host name will find it via the standard search mechanism. As part of the conversion, I re-worked the test harness code and expanded it to be a lot more complete. The output of the new test harness with the unmodified Mapper code matches identically the output of the modified mapper. IOW, I'm 99% confident that the behavior of the Mapper matches the old Mapper. The time differential between the two runs is around 500ms over 1 million iterations. I.E. the original code runs in 8000 ms for 1 million iterations of the testing code, while the new code takes 8500ms. The new code adds approximately 0.05 % to the time for a lookup. I am running the modified mapper code with 5.5.9 on an installation that has 40 hosts configured and it seems to be working correctly. I'd really appreciate it if a committer would get this added to the source tree. The complete modified Mapper.java file can be downloaded from: http://www.mhsoftware.com/~gsexton/Mapper.java If a decision is made to reject this patch, I'd appreciate knowing why. If there's something wrong from a coding or style perspective, I'd be happy to fix things. -1 for lower performance and questionable use case. (I didn't get the patch, but I don't really wish to) 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
OK, if I'm hearing (almost everyone) the issues to address are: 1) Sync getHosts() and getContextNames() 2) Figure out some sort of rate-limiting mechanism to limit DOS - Perhaps this should be configurable with # 3 below. 3) Make wild card matching a configurable option. A question for Yoav - At what entity should this mapper option be set ? Engine? Service? George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Yoav Shapira [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 9:02 AM To: 'Tomcat Developers List' Subject: RE: Code Submission - Wild Card Aliases Hi, The performance impact is not that big. If it was a configurable option, e.g. enableAliasWildcardMatching, turned off by default, I'd be OK with it. Yoav -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 10:04 AM To: Tomcat Developers List Subject: Re: Code Submission - Wild Card Aliases George Sexton wrote: I have completed the coding in o.a.t.u.http.mapper.Mapper to implement wild-card aliases. If a request for a host is made, and that host is not found, the code tests the host and aliases list and looks for wild-cards. So, a host name of www.mydomain.com would match an alias of *.mydomain.com. This additional level of testing is only done if the the presented host name is not found in the standard host list. Once a host is found via wild- card, it is added to the standard host list. Subsequent requests for that host name will find it via the standard search mechanism. As part of the conversion, I re-worked the test harness code and expanded it to be a lot more complete. The output of the new test harness with the unmodified Mapper code matches identically the output of the modified mapper. IOW, I'm 99% confident that the behavior of the Mapper matches the old Mapper. The time differential between the two runs is around 500ms over 1 million iterations. I.E. the original code runs in 8000 ms for 1 million iterations of the testing code, while the new code takes 8500ms. The new code adds approximately 0.05 % to the time for a lookup. I am running the modified mapper code with 5.5.9 on an installation that has 40 hosts configured and it seems to be working correctly. I'd really appreciate it if a committer would get this added to the source tree. The complete modified Mapper.java file can be downloaded from: http://www.mhsoftware.com/~gsexton/Mapper.java If a decision is made to reject this patch, I'd appreciate knowing why. If there's something wrong from a coding or style perspective, I'd be happy to fix things. -1 for lower performance and questionable use case. (I didn't get the patch, but I don't really wish to) 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code Submission - Wild Card Aliases
Let me see what I can do. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 1:32 PM To: Tomcat Developers List Subject: Re: Code Submission - Wild Card Aliases - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Tuesday, May 03, 2005 10:44 AM Subject: Re: Code Submission - Wild Card Aliases Peter Rossbach wrote: I also thing that the impact is small but the feature is very usefull. A connector option enableAliasWildcardMatching was a good idea. +1 for the patch again. -1 for it. I'm with Remy on this: -1 for the patch as is. The HashMap is just a really bad idea. Rémy 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: Unique Session ID's - are they really generated?
It sounds like you are talking about IIS, where the session ID was the memory handle to the session object George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Steven Pannell [mailto:[EMAIL PROTECTED] Sent: Monday, May 02, 2005 8:05 AM To: 'tomcat-dev@jakarta.apache.org' Subject: Unique Session ID's - are they really generated? Hi, On some application servers I have used in the past when you shut them down and restarted the server it was possible that duplicate session ID's were generated matching those in a previously running instance of the server. Does anyone know if tomcat really has Unique Session ID creation. That is I leave tomcat running for a week. Stop it. Start it. Is it possible that a duplication session ID will be created in my new running instance that matches a session ID created in my previous running instance. I just want to know does tomcat really guarantee unique Session ID's even over shutdown and start ups?? Thanks, Steve. - 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]
Code Submission - Wild Card Aliases
I have completed the coding in o.a.t.u.http.mapper.Mapper to implement wild-card aliases. If a request for a host is made, and that host is not found, the code tests the host and aliases list and looks for wild-cards. So, a host name of www.mydomain.com would match an alias of *.mydomain.com. This additional level of testing is only done if the the presented host name is not found in the standard host list. Once a host is found via wild-card, it is added to the standard host list. Subsequent requests for that host name will find it via the standard search mechanism. As part of the conversion, I re-worked the test harness code and expanded it to be a lot more complete. The output of the new test harness with the unmodified Mapper code matches identically the output of the modified mapper. IOW, I'm 99% confident that the behavior of the Mapper matches the old Mapper. The time differential between the two runs is around 500ms over 1 million iterations. I.E. the original code runs in 8000 ms for 1 million iterations of the testing code, while the new code takes 8500ms. The new code adds approximately 0.05 % to the time for a lookup. I am running the modified mapper code with 5.5.9 on an installation that has 40 hosts configured and it seems to be working correctly. I'd really appreciate it if a committer would get this added to the source tree. The complete modified Mapper.java file can be downloaded from: http://www.mhsoftware.com/~gsexton/Mapper.java If a decision is made to reject this patch, I'd appreciate knowing why. If there's something wrong from a coding or style perspective, I'd be happy to fix things. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code Submission - Wild Card Aliases
Peter,
I have no feeling one way or the other on synchronizing the getHosts() call.
Since there was very little synchronization in the original code, I didn't
do any in the new code.
I have never used junit, so I'm not sure I'm a good candidate for putting
the test harness code into it. Sorry...
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-Original Message-
From: Peter Rossbach [mailto:[EMAIL PROTECTED]
Sent: Monday, May 02, 2005 10:28 PM
To: Tomcat Developers List
Subject: Re: Code Submission - Wild Card Aliases
Hey Geroge,
I review the mapper patch. Cool!
I think getHosts is a little bit strange:
What you think about this:
public String[] getHosts() {
Host[] hosts ;
synchronized(this) {
hosts=new Host[hmHosts.size()];
hosts=(Host[])hmHosts.values().toArray(hosts);
}
String[] hostNames=new String[hmHosts.size()];
for ( int i = 0; i hosts.length; i++ ) {
hostNames[i] = hosts[i].name;
}
return hostNames ;
}
I thing sync is needed. I miss that also at orginal mapper. The host
values get array you also coded at getContextNames().
Can we change getHost to be protected.
Have you wrote junit testcases for the Mapper ?
Please, extract the testcode. I hate those test code inside
production code :-)
I find you patch very usefull!
Thanks
Peter
George Sexton schrieb:
I have completed the coding in o.a.t.u.http.mapper.Mapper to
implement
wild-card aliases.
If a request for a host is made, and that host is not found,
the code tests
the host and aliases list and looks for wild-cards.
So, a host name of www.mydomain.com would match an alias of
*.mydomain.com.
This additional level of testing is only done if the the
presented host name
is not found in the standard host list. Once a host is found
via wild-card,
it is added to the standard host list. Subsequent requests
for that host
name will find it via the standard search mechanism.
As part of the conversion, I re-worked the test harness code
and expanded it
to be a lot more complete. The output of the new test
harness with the
unmodified Mapper code matches identically the output of the modified
mapper. IOW, I'm 99% confident that the behavior of the
Mapper matches the
old Mapper.
The time differential between the two runs is around 500ms
over 1 million
iterations. I.E. the original code runs in 8000 ms for 1
million iterations
of the testing code, while the new code takes 8500ms. The
new code adds
approximately 0.05 % to the time for a lookup.
I am running the modified mapper code with 5.5.9 on an
installation that has
40 hosts configured and it seems to be working correctly.
I'd really appreciate it if a committer would get this added
to the source
tree.
The complete modified Mapper.java file can be downloaded from:
http://www.mhsoftware.com/~gsexton/Mapper.java
If a decision is made to reject this patch, I'd appreciate
knowing why. If
there's something wrong from a coding or style perspective,
I'd be happy to
fix things.
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wild Card Aliases - Help Following Source Code
Thanks for the pointer. I'm with you on not putting a REGEX in every call. My implementation for my software stores the resolved host name matches in a hashtable for fast access. It's only when a new host name shows up that it does a REGEX. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Friday, April 22, 2005 12:18 PM To: Tomcat Developers List Subject: Re: Wild Card Aliases - Help Following Source Code Host mapping is done by o.a.t.u.http.mapper.Mapper. This is critical-path stuff, so I'd likely be -1 to adding regexp here, unless it was optional and off by default. - Original Message - From: George Sexton [EMAIL PROTECTED] To: 'Tomcat Developers List' tomcat-dev@jakarta.apache.org Sent: Friday, April 22, 2005 9:38 AM Subject: Wild Card Aliases - Help Following Source Code I'm hoping someone can help me follow the source code. I'd like to lok at adding a feature, but I keep getting turned around when I try to follow the object hierarchy.b b Basically what I want to do is add wild-card aliases. I have a web calendar application. At a customer request, I have added a feature that allows one instance of my application to display different sets of calendars to users depending upon the host name that is used to hit the site. Internally, my application uses a different GUEST user based on the host name presented. Since we host this particular customer, it would be really nice if we could set it up so that any requests for domain.xxx, regardless of the rest of the host name would be forwarded to his application. We host about 45 people on this machine so going with a dedicated IP and making that host the default host that IP address won't really work. Each customer that we host has their own unique virtual host. So far, Tomcat is handling this really well. We are not using Apache as a front-end, and would really rather not. Adding apache would double our administration effort for deploying hosts. Adding wild-card virtual host aliases would neatly solve this problem. Where I'm having a problem understanding the source, is determining how the correct host is picked to forward the request into. If I could understand the flow I could probably sort out how to add support for this and submit it as a patch. The implementation I used within my application is, I think pretty efficient and doesn't add a lot of overhead. Basically, internally the steps I follow are: Lookup the host name in a Hashmap. Is this a new virtual host? No, return the associated user. Yes, this is new get the list of virtual host names iterate over the list trying a string match and regular expression match for each configured entry. When a match is found, sort the user name in the hash table, using the host name as the key. If no match is found, return the default name. Return the correct user. This implementation lets me only go through the pain of trying to do a string or regular expression match the first type a new host name is presented. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - 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: DO NOT REPLY [Bug 32811] - sendRedirect does not commit
I'm too lazy to use bugzilla on this:
What in the standard makes anyone here think processing of the JSP/Servlet
terminates once a HttpServletResponse.sendRedirect() is encountered?
This is a common fallacy of people moving from ASP.
YOU ALWAYS NEED A RETURN STATEMENT IMMEDIATELY FOLLOWING A
sendRedirect()!!
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 23, 2004 9:52 AM
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 32811] - sendRedirect does not commit
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=32811.
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=32811
--- Additional Comments From [EMAIL PROTECTED]
2004-12-23 17:51 ---
I'm surprised that page compiles in Jetty.
Doesn't it use the Jasper compiler as well?
AFAIK, sendRedirect and throw statements always need to be
contained in a branch if there is any code after them.
I would, however, expect this page to return a redirect instead of
a server error. I tested with 5.0.30 and it compiled but
returned a server 500
error.
%
if(request.getParameter(test) == null){
response.sendRedirect(/index.jsp);
}
if(request.getParameter(test) == null){
throw new Exception(Can't Redirect);
}
%
--
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.0.28 release
How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. I am really against this. I use CATALINA_HOME and CATALINA_BASE. The reason that I use them is that they provide a clean way of upgrading frequently. It lets me maintain a stock Tomcat Directory, with all of my customization (conf files, etc) in a separate directory. Please don't drop this functinality. George Sexton MH Software, Inc. - Home of Connect Daily Web Calendar http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ISAPI and SSI w/ IIS
I have been playing with trying to server side include a URL that is in a context handled by the ISAPI redirector. This is on Windows Server 2003 with isapi_redirector2.dll version 2.0.4. The chain is something like this: URL /calendar/OutputCurrentWeek.html is in a context handled by the ISAPI Filter. Directly invoking this URL produces output. Attempting to invoke the URL via SSI as shown below fails: !-- #include virtual=/calendar/OutputCurrentWeek.html?calendar_id=2 -- I'm pretty sure that what is happening is the SSI handler is not passing the request through the ISAPI filter chain. I also tried something like: !-- #exec isa=/jakarta/isapi_redirector2.dll?/calendar/OutputCurrentWeek.html?calenda r_id=2 -- And !-- #exec cgi=/jakarta/isapi_redirector2.dll?/calendar/OutputCurrentWeek.html?calenda r_id=2 -- The last two trys generated 500 errors. Does anyone have any ideas on how I can do a server side include to a context URL? As a fallback, I can use some code to invoke the URL using a Microsoft.XMLHTTP control, and retrieving the body text. Any ideas are appreciated. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Workers2.properties.sample
Using the isapi_redirector2.dll file, and this this workers2.properties, the URI for /calendar doesn't work if I Uncomment the group= line. This leads me to believe the group= line should contain lb:lb and not lb as shown in the /examples URI in the referenced file. If this is indeed the case, someone should update the sample file. [shm] info=Scoreboard. Requried for reconfiguration and status with multiprocess servers. file=anon # Defines a load balancer named lb. Use even if you only have one machine. [lb:lb] # Example socket channel, override port and host. [channel.socket:localhost:8009] port=8009 host=127.0.0.1 # define the worker [ajp13:localhost:8009] channel=channel.socket:localhost:8009 group=lb [status:] info=Status worker, displays runtime information [uri:/calendar/*] info=Connect Daily Web calendar #group=lb #[uri:/jkstatus/*] #info=The Tomcat /jkstatus handler #group=status: George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Source for Tomcat.exe
Can someone tell me where to find the source for Tomcat.EXE? There seem to be some issues in it relating to StartParams and StopParams. George Sexton MH Software, Inc. Voice: 303 438 9585 http://www.mhsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Source for Tomcat.exe
My bust. I mean tomcat5.exe -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Thursday, May 27, 2004 8:39 AM To: [EMAIL PROTECTED] Subject: Source for Tomcat.exe Can someone tell me where to find the source for Tomcat.EXE? There seem to be some issues in it relating to StartParams and StopParams. George Sexton MH Software, Inc. Voice: 303 438 9585 http://www.mhsoftware.com - 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: Source for Tomcat.exe
Thanks. Someone might annotate the README.TXT in jakarta-tomcat-5.0.25-src\jakarta-tomcat-connectors\procrun to point there. Also, can anyone explain why this file set is tacked into the Connectors directory? George Sexton MH Software, Inc. Home of Connect Daily Web Calendar Software http://www.mhsoftware.com/connectdaily.htm Voice: 303 438 9585 -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Thursday, May 27, 2004 9:00 AM To: 'Tomcat Developers List' Subject: RE: Source for Tomcat.exe Check the Jakarta-commons/daemon package or... http://cvs.apache.org/viewcvs.cgi/jakarta-commons/daemon/src/native/nt/p rocr un/ MT. -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: 27. svibanj 2004 16:51 To: 'Tomcat Developers List' Subject: RE: Source for Tomcat.exe My bust. I mean tomcat5.exe -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Thursday, May 27, 2004 8:39 AM To: [EMAIL PROTECTED] Subject: Source for Tomcat.exe Can someone tell me where to find the source for Tomcat.EXE? There seem to be some issues in it relating to StartParams and StopParams. George Sexton MH Software, Inc. Voice: 303 438 9585 http://www.mhsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] unsubscribe stupid users with auto-replies
I think a bigger issue is why is the list software forwarding these? I have subscribed to many other lists, and this seems to be the only one that consistently has this problem. This is pretty amazing considering the low number of subscribers. -Original Message- From: Guenter Knauf [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 6:09 PM To: [EMAIL PROTECTED] Subject: [OT] unsubscribe stupid users with auto-replies Hi all, I think that it is only fair for all others that those on the list which are too stupid to setup a separate mail account are directly unsubscribed once the list gets auto-replies about their absence. We have already enough spam, and its nearly impossible to filter those senseless mails. If this continues it will not last long till those who really want to follow the list and post useful stuff will leave - but then the problem is also solved because: no real posts = no stupid auto-replies = dead list. thanks, Guenter. - 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: [OT] unsubscribe stupid users with auto-replies
Perhaps it is a combination of two things. On other lists like Linux-Kernel, subscribers are not clueless enough to use an auto-responder that replies to messages that have Precedence: bulk set. Additionally, most UNIX auto-responders will only send one notice per configurable time period (i.e. a week). Also, I think that other lists are running a filter up-front that removes messages that are from auto-responders. The list plainly is filtered already for spam (X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N). Why doesn't it filter for out of office messages? George Sexton MH Software, Inc. Home of Connect Daily Web Calendar Software http://www.mhsoftware.com/connectdaily.htm Voice: 303 438 9585 -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 9:07 AM To: Tomcat Developers List Subject: RE: [OT] unsubscribe stupid users with auto-replies Hi, I think a bigger issue is why is the list software forwarding these? Why wouldn't it? It's a message sent to the list from a subscribed address. I have subscribed to many other lists, and this seems to be the only one that consistently has this problem. This is pretty amazing considering the low number of subscribers. The list probably has many more members than you think, but a silent majority. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: Behaviour of load-on-startup=0
Load on startup should really be deprecated because it duplicates
functionality available via context event listeners.
As a warning, there is some variance in servlet engines. The spec says 0
starts before 1, logically -1 should load before 0. In fact, some
containers (like Websphere if I remember correctly) don't process
entries with a value less than 0.
My practical advice to you is to look at context event listeners.
-Original Message-
From: Michael Prescott [mailto:[EMAIL PROTECTED]
Sent: Monday, March 08, 2004 10:44 AM
To: [EMAIL PROTECTED]
Subject: Behaviour of load-on-startup=0
I stumbled on what I think is a small difference in Tomcat's behaviour
from
the Servlet spec. Looking at the code, it seems to affect both Tomcat 4
and
5.
In short, the servlet specs (2.3 and 2.4) says that a servlet with
load-on-startup value set to 0 should load before those with values of
1
or higher, but Tomcat loads 1+ first, and 0 last.
The load-on-startup element indicates that this servlet should be
loaded
(instantiated and have its init() called) on the startup of the web
application. The optional contents of these element must be an integer
indicating the order in which the servlet should be loaded. If the value
is
a negative integer, or the element is not present, the container is free
to
load the servlet whenever it chooses. If the value is a positive integer
or
0, the container must load and initialize the servlet as the application
is
deployed. The container must guarantee that servlets marked with lower
integers are loaded before servlets marked with higher integers. The
container may choose the order of loading of servlets with the same
load-on-start-up value.
Here's the first part of loadOnStartup(Container[]). This code is
identical
in Tomcat 4.x (StandardContext.java:3398) and 5.x
(StandardContext.java:3930).
public void loadOnStartup(Container children[]) {
// Collect load on startup servlets that need to be initialized
TreeMap map = new TreeMap();
for (int i = 0; i children.length; i++) {
Wrapper wrapper = (Wrapper) children[i];
int loadOnStartup = wrapper.getLoadOnStartup();
if (loadOnStartup 0)
continue;
if (loadOnStartup == 0) // Arbitrarily put them last
loadOnStartup = Integer.MAX_VALUE;
Integer key = new Integer(loadOnStartup);
ArrayList list = (ArrayList) map.get(key);
if (list == null) {
list = new ArrayList();
map.put(key, list);
}
list.add(wrapper);
}
...
It appears the problem would be solved by deleting the lines that read:
if (loadOnStartup == 0) // Arbitrarily put them last
loadOnStartup = Integer.MAX_VALUE;
Michael
--
Michael Prescott
Ingenura Inc.
[EMAIL PROTECTED]
(416) 686-8576
PGP Public Key: http://www.ingenura.com/keys/MichaelPrescott.asc
-
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: [PATCH]Virtual Host Choice on HTML Manager
Here is my thinking. Of course, I am a lowly user and not a developer but I think it pretty much covers the issues. The major issues from my perspective are: 1) Admin cannot deploy privileged applications. This requires deploying manager by hand. 2) Admin cannot stop or restart applications. This requires using manager. 3) Manager already displays the status for all virtual hosts. This kind of breaks the virtual host purity that Remy and others want in this application. 4) Deployment of application using manager is difficult at best. I have never been able to do it. Even if you can do it, there are no configuration points. IOW, you cannot configure logging. 5) As Remy points out, people will next be asking for manager to manage virtual hosts. The biggest issue for me is that if you want to use a UI to manage tomcat, 3 different tools (Admin, Hand Edit, and Manager) must be used to create a virtual host that can be stopped and restarted. Doesn't anyone else see a problem with this? If I had my way, what I would do is: 1) Add capability for admin application to stop/start/re-start contexts. This really shouldn't be that big a deal. I cannot see any rationale for not putting it in. Additionally, I would put the status reports in the Admin app. If you do this, then I don't really care about the manager application and wouldn't even deploy it all. 2) Strip every feature except list, status, stop, and re-start from manager. IOW, remove the deployment capability and the complete server status feature (or limit it to the virtual host). How many people REALLY need to script deployment of a web application? Particularly in the limited fashion allowed by the current Manager? George Sexton MH Software, Inc. Home of Connect Daily Web Calendar Software http://www.mhsoftware.com/connectdaily.htm Voice: 303 438 9585 -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, January 12, 2004 9:04 AM To: Tomcat Developers List Subject: Re: [PATCH]Virtual Host Choice on HTML Manager TANAKA Yoshihiro wrote: on Tue, 6 Jan 2004 16:48:47 -0600 Glenn Nielsen [EMAIL PROTECTED] wrote: I'll try to modify as follows: 1)Make new classes extend HTMLManagerServlet ManagerServlet. 2)These servlets are optional. (commented out in web.xml) 3)Only admin role can access them. (by web.xml) Do you think I've it figured out? That sounds right. :-) I've done and put them on http://www.ytp.ne.jp/tech/tomcat/manager/index.html I modified existing classes to allow them to be extended, but did not change their functions. Also I create a new build file for Deployer named 'build-muti.xml' cause of security. I hope committers evaluate and commit them. While I appreciate the effort, I don't like your patch right now, sorry :-( Why add complexity when it is so simple to deploy the manager webapp on a new host ? Note: A webapp doesn't use any noticeable amount of resources in TC 5 (no background thread, no nothing). I suppose if there weren't all the changes to the default manager, I would have nothing against the patch (although I do hate the changes to the Ant tasks; it's really counter productive, and proves this is a bad design: the place of the vhost is in the URL). Soon, there will be requests to add host management in the manager webapp, and it will become a big mess. If there's interest in improving the management tools, fine, but there should be a thinking process before the hacking starts. Fixes were added a few days ago to the admin webapp to support dynamic host creation. This is a first step. It should then be possible to add a manager to a newly created host using the admin webapp (and then you're done, no hacks required). The biggest problem is probably that the admin webapp is not scriptable at all. 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: [PATCH]Virtual Host Choice on HTML Manager
Cool. I hope it is accepted. I run a lot of virtual hosts and it would be nice to have this. -Original Message- From: TANAKA Yoshihiro [mailto:[EMAIL PROTECTED] Sent: Sunday, January 04, 2004 9:11 AM To: [EMAIL PROTECTED] Subject: [PATCH]Virtual Host Choice on HTML Manager Hi, Happy New Year! I wrote patches that allow to choose any virtual host of Tomcat when you operate HTML Manager, Manager Servlet, and Deployer. I put patches and screen shots on: http://www.ytp.ne.jp/tech/tomcat/manager/index.html I hope committers would try and apply the patches. It's my pleasure to debug, if any. Regards. -- TANAKA Yoshihiro / http://www.ytp.ne.jp/ --- - 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: mod_jk will only connect to tomcat on the localhost
Looks to me like you have a firewall running. What does iptables -L show? -Original Message- From: Peter Anning [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 6:29 AM To: [EMAIL PROTECTED] Subject: mod_jk will only connect to tomcat on the localhost Hi, I have configured Apache 1.3 with mod_jk on SuSE Linux SLES8 on a zSeries. mod_jk will only connect to tomcat on the localhost. detail One Linux instance runs the Web Server and one runs Tomcat 4.1.27 In order to test the config I installed tomcat on the web server machine and mapped the application /examples/ to forward to the local tomcat. this works fine. However when changing the config to point to a remote machine (see config below) I always get an error in the mod_jk error log (ajp_connect_to_endpoint, failed errno = 111.) The full log file is below I have used tcpdump -i any 'dst port 8009' (see output below) and this always indicates that mod_jk is trying to connect to the localhost whatever I put in the workers.properties file. To test network connectivity I have used 'telnet 192.168.13.10 8009' and I can connect to tomcat and see the connection occur in the remote tomcat log files. I have also included a tcpdump of this below. Has anyone seen anything similar. Best Rgds Peter config mod_jk configured (workers.properties) as follows: worker.list=worker1 worker.worker1.type=ajp13 worker.worker1.host=192.168.13.10 worker.worker1.port=8009 worker.worker1.lbfactor=50 worker.worker1.cachesize=10 worker.worker1.cache_timeout=600 worker.worker1.socket_keepalive=1 worker.worker1.socket_timeout=300 worker.worker1.local_worker=0 apache mount points are configured in httpd.conf JkWorkersFile /etc/httpd/conf/workers.properties JkLogFile /var/log/mod_jk.log JkLogLevel debug JkMount /examples/* worker1 JkMount /examples/*.jsp worker1 ### tcpdump while accessing the /examples/ www02:/etc # tcpdump -n -i any 'dst port 8009' 16:19:21.496621 127.0.0.1.33194 127.0.0.1.8009: S 3501290459:3501290459(0) win 32767 mss 16396,sa ckOK,timestamp 9268978 0,nop,wscale 0 (DF) 16:19:21.497287 127.0.0.1.33195 127.0.0.1.8009: S 3497571144:3497571144(0) win 32767 mss 16396,sa ckOK,timestamp 9268978 0,nop,wscale 0 (DF) 16:19:21.497733 127.0.0.1.33196 127.0.0.1.8009: S 3498859603:3498859603(0) win 32767 mss 16396,sa ckOK,timestamp 9268978 0,nop,wscale 0 (DF) telnet 192.168.13.10 8009 www02:/etc # tcpdump -n -i any 'dst port 8009' tcpdump: WARNING: Promiscuous mode not supported on the any device tcpdump: listening on any 16:19:07.631821 192.168.12.11.33193 192.168.13.10.8009: S 3495439382:3495439382(0) win 5840 mss 1 460,sackOK,timestamp 9267591 0,nop,wscale 0 (DF) [tos 0x10] 16:19:07.635099 192.168.12.11.33193 192.168.13.10.8009: . ack 3495439509 win 5840 nop,nop,timesta mp 9267592 9396807 (DF) [tos 0x10] # mod_jk log file [Mon Dec 22 16:19:21 2003] [jk_worker.c (162)]: wc_create_worker, about to create instance worker1 of ajp13 [Mon Dec 22 16:19:21 2003] [jk_ajp13_worker.c (108)]: Into ajp13_worker_factory [Mon Dec 22 16:19:21 2003] [jk_worker.c (171)]: wc_create_worker, about to validate and init worker1 [Mon Dec 22 16:19:21 2003] [jk_ajp_common.c (1178)]: Into jk_worker_t::validate [Mon Dec 22 16:19:21 2003] [jk_ajp_common.c (1198)]: In jk_worker_t::validate for worker worker1 co ntact is 192.168.13.10:8009 [Mon Dec 22 16:19:21 2003] [jk_ajp_common.c (1226)]: Into jk_worker_t::init [Mon Dec 22 16:19:21 2003] [jk_worker.c (187)]: wc_create_worker, done [Mon Dec 22 16:19:21 2003] [jk_worker.c (238)]: build_worker_map, removing old worker1 worker [Mon Dec 22 16:19:21 2003] [jk_worker.c (250)]: build_worker_map, done [Mon Dec 22 16:19:21 2003] [jk_worker.c (111)]: wc_open, done 1 [Mon Dec 22 16:20:18 2003] [jk_uri_worker_map.c (460)]: Into jk_uri_worker_map_t::map_uri_to_worker [Mon Dec 22 16:20:18 2003] [jk_uri_worker_map.c (477)]: Attempting to map URI '/examples/' [Mon Dec 22 16:20:18 2003] [jk_uri_worker_map.c (502)]: jk_uri_worker_map_t::map_uri_to_worker, Fou nd a context match worker1 - /examples/ [Mon Dec 22 16:20:18 2003] [jk_worker.c (132)]: Into wc_get_worker_for_name worker1 [Mon Dec 22 16:20:18 2003] [jk_worker.c (136)]: wc_get_worker_for_name, done found a worker [Mon Dec 22 16:20:18 2003] [jk_ajp_common.c (1355)]: Into jk_worker_t::get_endpoint [Mon Dec 22 16:20:18 2003] [jk_ajp_common.c (1079)]: Into jk_endpoint_t::service [Mon Dec 22 16:20:18 2003] [jk_ajp_common.c (280)]: Into ajp_marshal_into_msgb [Mon Dec 22 16:20:18 2003] [jk_ajp_common.c (413)]: ajp_marshal_into_msgb - Done [Mon Dec 22 16:20:18 2003] [jk_connect.c (116)]: Into jk_open_socket [Mon Dec 22 16:20:18 2003] [jk_connect.c (123)]: jk_open_socket, try to
RE: mod_jk will only connect to tomcat on the localhost
Ummm These are on different subnets. What are your netmasks: 192.168.12.11 - 192.168.13.10 tcpdump: WARNING: Promiscuous mode not supported on the any device tcpdump: listening on any 16:19:07.631821 192.168.12.11.33193 192.168.13.10.8009: S 3495439382:3495439382(0) win 5840 mss 1 460,sackOK,timestamp 9267591 0,nop,wscale 0 (DF) [tos 0x10] 16:19:07.635099 192.168.12.11.33193 192.168.13.10.8009: . ack 3495439509 win 5840 nop,nop,timesta mp 9267592 9396807 (DF) [tos 0x10] George Sexton MH Software, Inc. Home of Connect Daily Web Calendar Software http://www.mhsoftware.com/connectdaily.htm Voice: 303 438 9585 -Original Message- From: Peter Anning [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 8:00 AM To: Tomcat Developers List Subject: RE: mod_jk will only connect to tomcat on the localhost David, Here you go: Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 0.0.0.0:80090.0.0.0:* LISTEN tcp0 0 0.0.0.0:10980.0.0.0:* LISTEN tcp0 0 0.0.0.0:10990.0.0.0:* LISTEN tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:80800.0.0.0:* LISTEN tcp0 0 0.0.0.0:631 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:250.0.0.0:* LISTEN tcp0 0 :::22 :::* LISTEN Cheers Peter On Tue, 23 Dec 2003 15:05:10 +, David Cassidy wrote Can you run - on the tomcat server if linux netstat -tln if anything else ! netstat -an | grep tcp | grep LISTEN then we can see if you are actually listening on anything other than localhost :) david Peter Anning [EMAIL PROTECTED] To: 'Tomcat Developers List' tomcat- [EMAIL PROTECTED] g.com cc: Subject: RE: mod_jk will only connect to tomcat on the localhost 23/12/2003 14:05 Please respond to Tomcat Developers List I have investigated this a bit already and am pretty sure there is no firewall running on either machine: iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination P On Tue, 23 Dec 2003 07:25:45 -0700, George Sexton wrote Looks to me like you have a firewall running. What does iptables -L show? -Original Message- From: Peter Anning [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 6:29 AM To: [EMAIL PROTECTED] Subject: mod_jk will only connect to tomcat on the localhost Hi, I have configured Apache 1.3 with mod_jk on SuSE Linux SLES8 on a zSeries. mod_jk will only connect to tomcat on the localhost. detail One Linux instance runs the Web Server and one runs Tomcat 4.1.27 In order to test the config I installed tomcat on the web server machine and mapped the application /examples/ to forward to the local tomcat. this works fine. However when changing the config to point to a remote machine (see config below) I always get an error in the mod_jk error log (ajp_connect_to_endpoint, failed errno = 111.) The full log file is below I have used tcpdump -i any 'dst port 8009' (see output below) and this always indicates that mod_jk is trying to connect to the localhost whatever I put in the workers.properties file. To test network connectivity I have used 'telnet 192.168.13.10 8009' and I can connect to tomcat and see the connection occur in the remote tomcat log files. I have also included a tcpdump of this below. Has anyone seen anything similar. Best Rgds Peter config mod_jk configured (workers.properties) as follows: worker.list=worker1 worker.worker1.type=ajp13 worker.worker1.host=192.168.13.10 worker.worker1.port=8009 worker.worker1.lbfactor=50 worker.worker1.cachesize=10 worker.worker1.cache_timeout=600 worker.worker1.socket_keepalive=1 worker.worker1.socket_timeout=300 worker.worker1.local_worker=0 apache mount points are configured in httpd.conf JkWorkersFile /etc/httpd/conf/workers.properties JkLogFile /var/log/mod_jk.log JkLogLevel debug JkMount /examples/* worker1 JkMount /examples/*.jsp worker1 ### tcpdump while accessing the /examples/ www02:/etc # tcpdump -n -i any 'dst port 8009' 16:19:21.496621 127.0.0.1.33194 127.0.0.1.8009: S 3501290459
RE: Performance Recommendation
I have done performance testing of a real world app against Orion, Resin, Tomcat 3.3, 4.0, and 4.1 and noticed little or no difference. Certainly nothing significant enough to spend money on. -Original Message- From: Roozbeh Zabihollahi [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2003 6:00 AM To: [EMAIL PROTECTED] Subject: Performance Recommendation Hi, I am tomcat user, as all of readers know, tomcat is very good Jsp Container for developping and not good for production mode (cause of its performance). I installed and run 'RexIPAppServer' ,that says it has best performance, and compare Servlets it generates for JSPs and Tomcat Generated Servlets. I see 'RexIPAppServer' construct static strings that JSP page use with Static Strings. same as: static final char[] _jspText_18=\ \r\n .toCharArray(); but Tomcat doesn't distinguish (or it not want to do) between Static and Dynamic Strings and print them in dynamic way in service method. I want to ask from Tomcat Developers, that eather Tomcat Developers does not want to implement this feature or not? and, could you help me to develop this feature, because i think this is exponentialy improve performance. ^-^ Best Regards, Roozbeh Zabihollahi. __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ - 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: Anyone, please ????
I suppose upgrading 5 minor point releases to version 4.1.29 to see if the problem goes away didn't occur to you? -Original Message- From: L.Karam [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 6:10 AM To: [EMAIL PROTECTED] Subject: Anyone, please I have Tomcat 4.1.24 + IIS 5 + JK2. After Tomcat had been running for about 22 hours, Tomcat stop responding to HTTP request. Even when I type http://localhost:8080/, it is not responding. The only log error is in stderr log file: org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads are busy, waiting. Please increase maxThreads or check the servlet status75 75 Any ideas? Leandro Karam Quintas - 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/webapps/admin/host alias.jsp
Wow Remy! You rock! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 8:30 AM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-catalina/webapps/admin/host alias.jsp remm2003/11/18 07:30:06 Modified:webapps/admin/host alias.jsp Log: - Make alias name field longer (bug 24787). Revision ChangesPath 1.4 +1 -1 jakarta-tomcat-catalina/webapps/admin/host/alias.jsp Index: alias.jsp === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/host/alias.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- alias.jsp 23 Jan 2003 00:07:08 - 1.3 +++ alias.jsp 18 Nov 2003 15:30:06 - 1.4 @@ -57,7 +57,7 @@ bean:message key=host.alias.name/: /controls:label controls:data - html:text property=aliasName size=24 maxlength=24 styleId=aliasName/ + html:text property=aliasName size=24 maxlength=128 styleId=aliasName/ /controls:data /controls:row /controls:table - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.0.14 Welcome File Broken?
I set up 5.0.14 w/ a welcome file that is a mapped servlet, and the mapped resource is not returned as expected. I think this is a bug: servlet servlet-nameViewCal/servlet-name servlet-classcom.mhsoftware.cdaily.servlet.ViewCal/servlet-class /servlet servlet-mapping servlet-nameViewCal/servlet-name url-pattern/ViewCal.html/url-pattern /servlet-mapping welcome-file-list welcome-fileViewCal.html/welcome-file /welcome-file-list From the specification: SRV 9.10 If a web container receives a valid partial request, the web container must examine the welcome file list defined in the deployment descriptor. The welcome file list is an ordered list of partial URLs with no trailing or leading /. The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a resource in the WAR is mapped to that request URI. George Sexton MH Software, Inc. Voice: 303 438 9585 http://www.mhsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.0.14 Welcome File Broken? - NOT
Oops. That was really dumb of me. The welcome file list was commented out. I have really got to stop using VI to edit files... -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Sunday, November 09, 2003 2:58 PM To: [EMAIL PROTECTED] Subject: Tomcat 5.0.14 Welcome File Broken? I set up 5.0.14 w/ a welcome file that is a mapped servlet, and the mapped resource is not returned as expected. I think this is a bug: servlet servlet-nameViewCal/servlet-name servlet-classcom.mhsoftware.cdaily.servlet.ViewCal/servlet-class /servlet servlet-mapping servlet-nameViewCal/servlet-name url-pattern/ViewCal.html/url-pattern /servlet-mapping welcome-file-list welcome-fileViewCal.html/welcome-file /welcome-file-list From the specification: SRV 9.10 If a web container receives a valid partial request, the web container must examine the welcome file list defined in the deployment descriptor. The welcome file list is an ordered list of partial URLs with no trailing or leading /. The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a resource in the WAR is mapped to that request URI. George Sexton MH Software, Inc. Voice: 303 438 9585 http://www.mhsoftware.com - 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]
More Admin Application: Service Reloading Question
I am evaluating Tomcat 5.0.14 for use in a ASP Hosting environment. As part of this environment I would need to routinely create (or destroy) virtual hosts. One major showstopper seems to be that if I create a virtual host and click on the Commit Changes, then the service reloads, including all of the virtual hosts, and their associated contexts. Is there some setting I don't see that can affect this restarting behavior? Without the capability to create virtual hosts on the fly, I will have to schedule routine re-starts of the servlet engine. This is really less than optimal. Any ideas would be appreciated. George Sexton MH Software, Inc. Voice: 303 438 9585 http://www.mhsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Order of parameters
The solution is to pass a fields list as an additional paramter, and use that field list to drive the ordering of your form. -Original Message- From: Martin van Dijken [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 4:16 AM To: Tomcat Developers List Subject: RE: Order of parameters MOST browsers; certainly not all. 100% true If you are requiring order it may makes the most sense to NOT trust the wire - but do the ordering yourself on entry as described. Well, the reason I'm proposing this is I'm modifying a form handler which simply mails all fields encountered to a specific mail address. It works quite well, but is totally unusable because the person who gets the email gets a totally unreadable mail where firstname is after street, then comes his email address, etc.etc. This idea may not be one which leads to safe habits. Well, the usage of getParameterNames or getParameterMap always has those problems. Anybody can add something to the querystring and even http manipulation isn't that hard. This is up to programmers' discretion I think. Martin - 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: [4.1.23] Deprecating mod_webapp
Well, I'll grant the majority of your points, and even allow how the combination of the web server and the servlet engine could be considered the application. I still think this is a bad idea, and here is my reasoning. Before anyone writes this kind of thing they should examine a representative number of web applications and find out how many would actually benefit. I.E. how many web applications have significant amounts of static data within their context. To know the true effect, it would further be necessary to have some feel for how much overhead looking at each request and routing it correctly would add. Remember that this new code would now add new overhead to every request that was destined for a servlet. Additionally, you would have to have some approximation of how many web applications use constructs that would totally defeat the module. I.E. filters mapped to /*. I think a lot of people using filters are doing this. In my applications, the vast majority of CPU time and energy is spent on database queries, and creating output. I have very little static content within my application directory. Perhaps a few icons. The performance benefit of handing those requests to Apache versus Tomcat is minimal and would not be noticed. I would probably get a much more noticeable performance increase by optimizing queries, output creation, etc. It seems to me that if your Application design has a great deal of static content within the web application path it would be much simpler, and even less overhead to simply place that static content in a plain static directory and have it served by Apache. Why even have the overhead of a modules that sorts out the requests? While I have to say this breaks the Servlet API deployment guidelines it would be justified. I don't think an application of this nature (high ratio of static content to active content) is the kind that would have to be deployed to a large number of servers. If it did, it would most likely be in a clustering scenario where you would use different methods to roll out changes anyhow. Its your choice. If you think this is really a superior idea, then by all means go ahead and work on it. Personally, I would like to see fewer, but more robust connectors rather than more connectors that are not as solid, but that's my point of view. -Original Message- From: Endre Stølsvik [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2003 2:22 AM To: Tomcat Developers List Subject: Re: [4.1.23] Deprecating mod_webapp On Wed, 19 Mar 2003, George Sexton wrote: | From a purely practical standpoint, that would be terribly complicated. | Mod_webapp would have to read and fully understand the web.xml and all of | the servlet mappings. This is made even more impossible by the addition of | filters to the Servlet API. Impossible?!? | How can mod_webapp even begin to guess at the hidden logic contained | within a filter? Well, it would have to forward requests that were filtered, OF COURSE, since that includes bytecode. | It is totally impossible. It's not clear to me that you could feasibly | implement this kind of front end and incur less overhead that simply | passing the request to the servlet engine. Even if you could, at the end | of the day, it would still be non-compliant because the last sentence of | the second paragraph of section 3.1 of the Servlet API 2.3 Spec says: | | all requests that begin with the /catalog request path, known as the | context path, are routed to the web application associated with the servlet | context. Read: web application. Not Servlet Container. If you absorb the fact that Apache and Tomcat would _work together_ combining forces as being the Servlet Container, then the above statement would hold true. One does encryption (read: SSL) on the Apache side, even though you have to forward parts of that to Tomcat. This is just as deviant from the specs you're referring to, as, considering the web.xml, apache serves static files himself, not bothering his java-executing part of the (combined) Servlet Container to do this.. | | I quoted this exact spec to a client because they wanted to do what you | propose, only their engine is not smart enough to parse the web.xml. they | wanted me to rename all of my pages to end in .jsp so that it would get | forwarded. What's the idea here?! | | To be compliant, the spec must be fulfilled. ALL requests for the context | path must be forwarded to the application. Read again: THE APPLICATION. Right. Running in the Servlet Container. WHICH IS the Apache+Tomcat COMBINATION when you run it with mod_WHATEVER inside of Apache. How would you interpret a Servlet Container that was coded exclusively in C++, not having any normal JVM, simly acting as the VM itself by interpreting bytecode? And then, what if you split these thing slightly apart, using a (standard) JVM to execute the bytecode? And then, having the JVM run standalone, using a communication channel of some sort to make
RE: [4.1.23] Deprecating mod_webapp
From a purely practical standpoint, that would be terribly complicated. Mod_webapp would have to read and fully understand the web.xml and all of the servlet mappings. This is made even more impossible by the addition of filters to the Servlet API. How can mod_webapp even begin to guess at the hidden logic contained within a filter? It is totally impossible. It's not clear to me that you could feasibly implement this kind of front end and incur less overhead that simply passing the request to the servlet engine. Even if you could, at the end of the day, it would still be non-compliant because the last sentence of the second paragraph of section 3.1 of the Servlet API 2.3 Spec says: all requests that begin with the /catalog request path, known as the context path, are routed to the web application associated with the servlet context. I quoted this exact spec to a client because they wanted to do what you propose, only their engine is not smart enough to parse the web.xml. they wanted me to rename all of my pages to end in .jsp so that it would get forwarded. To be compliant, the spec must be fulfilled. ALL requests for the context path must be forwarded to the application. To do otherwise is not compliant with the spec. A specification is like a map through a mine field. You must do precisely what it says, without expansion, or interpolation. If you do otherwise, you will at the least blow your foot off. In our case, by scrupulously following the spec, we have an application that has been tested on 6-8 servlet engines with only one small tweak to work around a bug in one of them. Deviation from the specification, even in the name of imagined efficiency is not acceptable. This is particularly true of Tomcat since it has the role of Reference Implementation. George Sexton MH Software, Inc. Home of Connect Daily Web Calendar Software http://www.mhsoftware.com/connectdaily.htm Voice: 303 438 9585 -Original Message- From: Endre Stølsvik [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2003 2:06 AM To: Tomcat Developers List Subject: Re: [4.1.23] Deprecating mod_webapp On Mon, 17 Mar 2003, George Sexton wrote: | It's also horribly broken and not compliant with the servlet API. | Specifically, it doesn't forward all requests within the context to the | servlet engine, but attempts to let Apache fulfill static requests. Isn't that one of the good reasons for having Apache as frontend? Serving (largish) images and other static files (e.g. stylesheets, XML, dtds etc) could be much mor effectively done by Apache, instead of using IPC of some kind to an Java engine, which had to parse and serve the request.. I mean, there are _large_ overheads that could be avoided.. If the mod_webapp served static requests, but honored the web.xml file _completly_, then it would be great, right? -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ - 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: [4.1.23] Deprecating mod_webapp
It's also horribly broken and not compliant with the servlet API. Specifically, it doesn't forward all requests within the context to the servlet engine, but attempts to let Apache fulfill static requests. -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 2:34 AM To: Tomcat Developers List Subject: [4.1.23] Deprecating mod_webapp Hi, I'd like to officially deprecate mod_webapp in Tomcat 4.1.23. It is no longer maintained, and will not work with Tomcat 5.0 (at least it won't unless people contribute stuff). Remy - 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: [4.1.22] Stability rating
Works for me. -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 7:12 AM To: Tomcat Developers List Subject: [4.1.22] Stability rating ballot [ ] Alpha [ ] Beta [X] Stable (GA) /ballot Remy - 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: [4.1.21] Stability rating
I tested my application on it and everything seems OK. FWIW, though, because I am not a committer. George Sexton MH Software, Inc. Home of Connect Daily Web Calendar Software http://www.mhsoftware.com/connectdaily.htm Voice: 303 438 9585 -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, February 27, 2003 8:52 AM To: Tomcat Developers List Subject: [4.1.21] Stability rating ballot [ ] Alpha [ ] Beta [X] Stable (GA) /ballot Please vote (after testing the release, if possible ;). Thanks, Remy - 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: JDK 1.4 - again
Fast is relative. I tested our App on Tomcat 4.0, 4.1, Resin, Orion, and OC4J. I was not able to come up with any noticeable difference in performance. If your application is database intensive, as our is, then the limiting factor is the database and not the application server. George Sexton MH Software, Inc. Home of Connect Daily Web Calendar Software http://www.mhsoftware.com/connectdaily.htm Voice: 303 438 9585 -Original Message- From: John Trollinger [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 20, 2003 5:13 AM To: 'Tomcat Developers List' Subject: RE: JDK 1.4 - again http://www.caucho.com/ It is pretty fast. A lot of ISPs seem to use it for providing jsp / servlets to their users. -Original Message- From: Steve Burrus [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 6:47 PM To: Tomcat Developers List Subject: Re: JDK 1.4 - again What do u mean by a Resin 3.0 anyway?? What kind of a web container is that? I have NEVER really heard about that ever before! Would you please humor me and tell me all this resin 3.0? You say that it's a lot faster than Tomcat. How can that possibly be. Tomcat is pretty fast. - 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]
