ironclaw hand wrote:
Andre,
Thank you for the detailed response I can see now that the config was probably
never actually quite right...
I have amended the log level to debug and I now can see this in the mod_jk.log file:
[Tue Apr 24 10:45:35.203 2012] [20188:3044006768] [debug]
jk_map_to_storage::mod_jk.c (3773): missing uri map for
sfta.a.b.c:/sft/announcement.jsp
[Tue Apr 24 10:45:35.266 2012] [20287:2844699504] [debug]
jk_map_to_storage::mod_jk.c (3773): missing uri map for
sfta.a.b.c:/sft/images/sft.css
[Tue Apr 24 10:45:35.269 2012] [20188:3033516912] [debug]
jk_map_to_storage::mod_jk.c (3773): missing uri map for
sfta.a.b.c:/sft/images/logo.gif
It looks like mod_jk is receiving from apache but it doesnt know what to do with the request. Is this correct?
Yes. mod_jk is looking at the URI pattern, and it does not match any pattern in the table
which it has built on the base of its JkMount directives. So it returns "declined" to
Apache, and Apache proceeds to serve that URI itself, as a "blob".
Actually, the mod_jk log, at the moment your httpd server is restarted, should show the
processing of the JkMount/jkUnmount directives, when mod_jk builds its "URI map" which it
refers to above.
What I am not quite sure about anymore, is what the mention in the loglines above of the
actual hostname means, It could be a function of your JkLogFormat directive, or it could
be that these requests are actually processed by the wrong VirtualHost.
I remember that this subject has come up previously on the list, but I don't remember
precisely in which context or when.
Maybe someone else can answer that.
If your Apache configuration is such that you have a separate access log for the different
VirtualHosts (and one for the "main" server), then you should be able to see which
requests go to which VirtualHost (independently of whether they are forwarded to Tomcat or
not).
I have been reading about this and people have suggested in other forum posts
to use:
JKMountCopy On - within the virtual host directive
I have tried this and it doesnt make any difference although I am assuming this
is because my JKMounts are actually defined within the virtual host and not
globally? If I run a tcpdump on port 8009 I never actually see any packets so
it never reaches tomcat again probably because of the missing uri map issue.
This takes us into the realm of understanding Apache's VirtualHost workings, and how
VirtualHosts inherit or not some configuration from the "main" configuration part.
I was hoping to avoid that part...
Generally, when a configuration directive is present in the "main" part of httpd.conf, it
acts as a default for all VirtualHosts. That is, it is valid in (or inherited by) each
VirtualHost, unless the <VirtualHost> section specifically overrides it.
JkMount/JkUnmount are an exception. They are not automatically inherited.
So either you put the JkMount/JkUnmount directives directly in each <VirtualHost> section
(as you seem to have done), or you use either one of two "tricks".
Trick #1 : in the main part of the configuration, you put the JkMount/JkUnmount
directives, and you add a "JkMountCopy all" directive. This causes the main
JkMount/JkUnmount directives to be copied to *all* VirtualHosts.
Trick #2 : in the main part of the configuration, you put the JkMount/JkUnmount
directives. In the select VirtualHosts in which you want to inherit the main
JkMount/JkUnmount directives, you add a "JkMountCopy on" directive. This will copy the
main configuration's JkMount/JkUnmount directives to *this* VirtualHost only.
Which one is best to use in your case is a matter of choice depending on your whole setup
(how many VirtualHosts you have and how similar they are).
As a side note would you reccommend dropping mod_jk and using mod_proxy as some
posts suggest?
That is your choice of yourse. But in my view, it is a bit like throwing out the baby
along with the bath water.
I personally prefer mod_jk, and find that it has a lot more configuration
options.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
