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]

Reply via email to