Re: Code Submission - Wild Card Aliases
George Sexton wrote: 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. I like it to some extent (haven't fully verified it, though), but I'm still not hot about adding the newly found hosts to the host list. Even if it's slower, I think I'd prefer a separate prefix matching step, since filling the list with new hosts is likely going to create problems and add special cases (ex: managing hosts when you have a host as www.foo.com and another less relevant *.foo.com). For exact matches (which is done in a few places inside Tomcat), using hash codes might work a bit faster, so it could be beneficial. Rémy - 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
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]
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]
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
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: 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]
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
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]
Re: Code Submission - Wild Card Aliases
On 5/2/05, George Sexton [EMAIL PROTECTED] 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. Is there any provision to things from the host list or to limit its size? It seems the behavior of adding wild-card matches to the host list can be easily exploited in a denial of service attack by simply requesting a lot of different host names matching some wild-card until the host list consume all available memory. Jin Yu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
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
+1 BTW, did there is provision to reduce search to only *.mydomain.com ? 2005/5/3, Yoav Shapira [EMAIL PROTECTED]: 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
Yoav Shapira wrote: 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. It's not an excuse to write inefficient code. Replicate that kind of stuff all over the place and you'll see the overall performance will be way worse. So making any exceptions for newly added code is bad. Rémy - 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
Hey Remy and George, I have analyse the patch and find it very usefull. When you have a lot of customer at one tomcat with a lot of virtual hosts and customer can change there subdomains mapping, this * Alias Feature is a great help. I have the next two week limit time, but I thing we can integrate the patch. The performance reduction is very small at production use case/envs. Vote +1 to add this patch with small modifications. . Peter Remy Maucherat schrieb: 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
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. Peter George Sexton schrieb: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Submission - Wild Card Aliases
George Sexton wrote: 0.05% lower is hardly a sufficient reason to reject this. Sure, but since it's my decision and not yours, it's a -1 at the moment. Please read my reply to Yoav. Again, you like the use case, while I think it is useless. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Submission - Wild Card Aliases
?? Jin Yu [EMAIL PROTECTED] : On 5/2/05, 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. Is there any provision to things from the host list or to limit its size? It seems the behavior of adding wild-card matches to the host list can be easily exploited in a denial of service attack by simply requesting a lot of different host names matching some wild-card until the host list consume all available memory. Jin Yu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ! \\\|/// \\ - - // ( @ @ ) oOOo- (_)-oOOo :gzlongzhijian QQ(OICQ) 40831127 Q :[EMAIL PROTECTED] :http://www.gzlzj.com 401 :510630 :020-33629058 Oooo oooO ( ) ( ) ) / \ ( (_/ \_) - Do You Yahoo!? 150MP3 1G1000
Re: Code Submission - Wild Card Aliases
Hey George,
the Mapper is create inside Connector.
I think we must setup the new Connector option before we start the
MapperListener inside Connector.start()
add connector and Mapper property enableAliasWildcardMatching at Connector
o.a.c.connector.Connector L1076
if( this.domain != null ) {
mapper.setEnableAliasWildcardMatching
(this.enableAliasWildcardMatching );
mapperListener.setDomain( domain );
//mapperListener.setEngine( service.getContainer().getName() );
mapperListener.init();
...
}
Peter
George Sexton schrieb:
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Submission - Wild Card Aliases
George Sexton wrote: 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. Your feature is uselss, so try to reduce the bloat it will cause: one field only. 3) Make wild card matching a configurable option. 4) Make an efficient implementation of the feature. Yours is not, and I will not withdraw my -1 until it is changed. A question for Yoav - At what entity should this mapper option be set ? Engine? Service? This is done with an attribute on the connector, which is then passed to the mapper. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: 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: 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]
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]
