RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c

[Bojan Smojver <bo...@rexursive.com>]

I think I understand what you're trying to say and I wouldn't like to
introduce a piece of code that fixes one thing and breaks a bunch of
them (load balancing, virtual serving etc.).

Let me submit this analysis. The static, local (to Apache) copy of
index.jsp (or whatever other file) will get picked up (i.e. its
existence will be recognised by mod_dir) only if:

- it actually exists (otherwise r->finfo.filetype will be 0)
- DirectoryIndex is set to pick the file up

So, if you have a load balancing scenario or virtual serving, don't use
DirectoryIndex and/or don't put files in you local file system, but use
other mechanisms (precompiled JSP's or let Tomcat pick the default file
up) for that. It is unrealistic to expect from Apache to pick up virtual
files, invisible to it from within the file system. And since it's
Apache that's doing mod_dir here, I don't think that we should go very
far into virtual land.

One other thing also. In the actual code, the file to be picked up is
now set as an absolute file name. However, if I do this at the end of
jk_map_to_storage():

--------------------------
r->filename = (char *)apr_filename_of_pathname(r->uri);
--------------------------

(i.e. make the file what it used to be, just make r->finfo.filetype =
1), the whole thing still works (minus the aliases, which is just a
plain bug). So, jk_handler() is making its own choice about what file
(physical or virtual) is going to get served, it doesn't rely on info in
r->filename at all. The only difference is that mod_dir gets that 1 set
in jk_map_to_storage() (done in the 'what if' sub request of mod_dir)
and then engages a real request a bit earlier. This is a request with
handler type "jakarta-servlet" and goes through mod_jk again. So, I'm
not sure that things would get broken anyway. But, it's a possibility,
in which case just don't use DirectoryIndex, since it doesn't make sense
anyway.

The old code (in mod_jk for Apache2 and mod_jk2 for Apache2) breaks
DirectoryIndex as compared to Apache 1.3.x and mod_jk 1.x. We can make a
few choices here:

- fix aliasing in the patch and explain to people how it really works
- let the patch into mod_jk 1.2.0, but not 2.x
- kick the patch out of both
- kick the patch out of both and change how 1.3.x/1.x combo works too
and then let people know about it

I can live with any of the above since I fully control my own
environment and can adjust accordingly.

Bojan

On Sun, 2002-07-21 at 21:20, Mladen Turk wrote:
> Just to prove the concept put the following in your workers2.properties
> 
> [uri:/*.jsp]
> info=Extension mapping
> 
> And then try your patches.
> 
> We are obviously having  some concept misunderstanding. I don't say that
> I'm happy with the current implementation of mod_jk2 and how it deals
> with the rewriting, but I think we shouldn't try to clarify that a bit.
> The problem is far more complex then it may look.
> 
> We have a two situations, with the TC on the same box as apache, and on
> the remote one. Well, that is only the partially correct, cause the load
> balancing brakes that.
> 
> So what we have is the following for example
> 
> /someapp/
> ------>/somelocation1/someapp/
> ------>/somelocation2/someapp/
> ------>10.0.0.1/someapp/
> ------>10.0.0.2/someapp/
> ...etc
> 
> Basically this is something like a reverse proxy situation.
> All that has to be mapped inside the apache's directory tree at the
> /opt/apache2 but can go to the any physical location above, or any
> virtual one. 
> You can serve the static mime-type context only from the first two
> cases. The Load balancer have no idea about the fact where the app is
> located (local or remote), so the .gif will get served according to the
> lb state, not its potential context performance, but that is another
> story.
> 
> Your patches brakes the entire lb concept, and that is the reason that I
> don't like it. Its not the problem with the static context (probably
> it's a performance gain), but the default index.jsp will get served only
> from the local TC no matter what the lb thinks about that. He may mark
> the 10.0.0.2 as a active env, and you will map that to a local
> /somelocation1.
> 
> What we need IMO is that lb informs the map_to_storage whether we are
> serving local or remote, so that we don't force the local context all
> the time if present.
> 
> > 
> > I mentioned in the previous e-mails that aliases have not 
> > been covered with this patch at all (that's why Mark's having 
> > problems with them). They would have to be dealt with as well.
> > 
> 
> As I said (perhaps I'm totally wrong) you shouldn't suppose that the
> context is inside the local file system. It has nothing to do with the
> static context serving, and you don't   have enough info to decide where
> the context is situated.
> 
> My suggestion are:
> 
> 1. Let see how can we get the info whether the context is from local or
> remote storage (and then use the map_to_storage accordingly)
> 2. Let the TC decide what the default served file will be for a
> particular uri (Dropping the entire DirectoryIndex fuzziness)
> 3. See how to enable the DirectoryRoot mapping
> 
> MT.
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>