tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Code Submission - Wild Card Aliases
Date Wed, 04 May 2005 17:45:14 GMT
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, would have one set of
> calendars, while 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message