tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Vowles" <rvow...@sew.co.nz>
Subject Re: Multi-homing/Virtual named hosts
Date Sat, 01 Apr 2000 12:07:08 GMT
----- Original Message -----
From: Costin Manolache <costin@eng.sun.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Saturday, April 01, 2000 6:19 PM
Subject: Re: Multi-homing/Virtual named hosts


> There are 3 steps for implementing virtual hosts:
> - change the configuration ( server.xml ) and find an intuitive way to
specify
> the
> virtual hosts ( maybe similar with other servers).
>
> - add a property to Context ( host for example ) and make sure we set it
at
> startup.

I don't quite understand why you are differentiating between these two - you
are saying something like adding a new element that defines a virtual host
and then another attribute in Context that indicates which VirtualHost(s) is
(are) being used. This seems to me to add unnecessary complexity, unless
what you are trying to do is make Tomcat a fully fledged VirtualHost
supporting web server, in which case it makes complete sense.

I haven't seen any "statement of objectives" for Tomcat (url?) so maybe I'm
missing something, is it the intention of this team to make Tomcat able to
operate like a fully functional web server?

If so, and given that I will be experimenting, any suggestions for tags - I
could make up my own, but again, if preferences exist...

> - change SimpleMapper to take into account the host property - that's the
only
> difficult part and the main reason we don't have it.
> The problem with SimpleMapper is that it's very... complex ( and is the
result
> of a long evolution and many fixes ). I would rather start a new mapper.

I suppose I had better look into it before making any value judgements!

> The mapper needs to:
> - define an efficient data structure. The most frequent operation is match
by
> prefix and vhost, then match by extension. Probably a tree or something
> - implement an efficient alghoritm - with a lot of care in parsing ( avoid
> string duplicates, etc)

Make sense - as long as I design to an interface, someone can replace my
implementation.

> You can also try to play with SimpleMapper, it shouldn't be difficult to
hack
> it, but I would rather spend the time writing a new one. There is a lot of
> theory about how to do efficient matching, and that is probably the most
> expensive operation in tomcat ( or any other server ).
>
> As a note, the API makes the parsing to be a 2 step process - you first
need to
> extract the context and then use the context config to parse the rest of
the
> request. It doesn't have to be implemented that way - it will be much
faster to
> do the full parsing in first step.
>
> I think this is one of the most important aspects of the current tomcat
design
> - we want to be able to be fast and reduce the overhead by using a smart
> alghortim, and the interceptor allows that - you'll have access to all the
> mappings and you can construct a global structure ( or partition it by
anything
> - you have control ).

So what you are saying is that you really want to replace the SimpleMapper
anyway, and if VirtualHost can be designed into it and it made faster, so
much the better.

> Please don't try to partition the problem by adding a VirtualHost object
and
> finding the host and then the context and so on. IMHO it's a bad
alghoritm, and
> doesn't fit the current model. I don't know how said it, but optimization
means
> choosing the right alghoritms and structures.

As I understand from what you just said, what you don't want is to add
another step to the process. You indicate above that it is currently a
two-step process, you don't want to add a third step? I will have to examine
the mechanism that is used at the moment to see how I can make this
possible.

Personally I don't really care at the moment about performance, I'd like to
get it operational as I want to use it on very low volume sites (10-20
requests per day), but once a mapper is written, I would be perfectly happy
to go back and discuss how to make it more efficient. I have another friend
who would like to use it on a high volume site, so it would be of personal
interest to make it work well.

Richard

---
Richard Vowles, Infrastructure Architect, Inprise New Zealand
home-email: "mailto:rvowles@sew.co.nz, work-email: "rvowles@inprise.com"




Mime
View raw message