On 12.07.2016 19:44, Wayne Li wrote:
Hi,
I have a servlet/jsp application running on tomcat 7.0.47. There are no
static html files.
Now I am try to use apache 2.4.7 (Ubuntu)
as the front and forward eveything to tomcat. I installed mod_jk using
Ubuntu's software
center.. Things are working. But I have errors in
/var/log/apache2/mod_jk.log:
[Mon Jul 11 20:19:32.261 2016] [1175:140389159810944] [info]
init_jk::mod_jk.c (3365): mod_jk/1.2.37 initialized
[Mon Jul 11 20:19:32.279 2016] [1175:140389159810944] [error]
extension_fix::jk_uri_worker_map.c (564): Could not find worker with name
'jk-manager' in uri map post processing.
[Mon Jul 11 20:19:32.279 2016] [1175:140389159810944] [error]
extension_fix::jk_uri_worker_map.c (564): Could not find worker with name
'jk-status' in uri map post processing.
[Mon Jul 11 20:19:32.386 2016] [1177:140389159810944] [info]
init_jk::mod_jk.c (3365): mod_jk/1.2.37 initialized
[Mon Jul 11 20:19:32.386 2016] [1177:140389159810944] [error]
extension_fix::jk_uri_worker_map.c (564): Could not find worker with name
'jk-manager' in uri map post processing.
[Mon Jul 11 20:19:32.386 2016] [1177:140389159810944] [error]
extension_fix::jk_uri_worker_map.c (564): Could not find worker with name
'jk-status' in uri map post processing.
If I add the following lines, the errors go away:
worker.list=jk-status
worker.jk-status.type=status
worker.jk-status.read_only=true
worker.list=jk-manager
worker.jk-manager.type=status
But the added line read funny. The same thing appears on the left-side of
the equal sign twice.
Are they correct? Do I need these lines? Can I ignore the errors?
Any information would be appreciated. Thanks in advance.
Tutorial :
Apache httpd knows /nothing/ about Tomcat. Whenever it gets a request, Apache httpd looks
at the request URI, and then inside itself for an appropriate "handler" to process that
request (and generate a response for it).
To do that, it passes the request successively through all the "handlers" which it knows
about (as per its configuration). Each handler gets a chance to look at the request URI,
and, if it is not "interested", it returns a status "declined" to Apache httpd.
Apache httpd, in such a case, passes the request to the next possible handler,
and so on.
The last handler in that chain is the Apache httpd "default handler", which always handles
the request, if nobody else before wanted it.
If some handler in the chain decides that this request URI "is for him", then instead of
returning "declined", it will compose and return the response to the request.
Apache then returns that response to the client, and stops scanning for more
handlers.
For Apache httpd, mod_jk is just one such "handler" : it gets every request to look at,
and decides if it wants to handle it or not. If it decides to handle it, then mod_jk
passes the request to Tomcat, which handles the request and generates a response, which
mod_jk then returns to Apache etc. Apache httpd is totally unaware that it is not mod_jk
itself which generates the response, and totally unaware that there are, in the
background, one or more Tomcat "workers" to do the real work.
So, how does mod_jk decide if it wants to handle a request or not ?
That is where the "JkMount" directives come into play.
These are not instructions for Apache, they are for mod_jk.
When Apache reads its configuration and encounters a directive which it does not
understand, it also passes it through the configured handlers, in case it is of interest
to one of them. When mod_jk receives such a line, it notes in an internal "URI mapping
table" that "URI's that look like this, are for me" (later), and they should be handled
(later) by "tomcat worker x". When it is finished reading the configuration, that table
thus looks like this :
URI_1 -> worker_a
URI_2 -> worker_a
URI_3 -> worker_b
URI_4 -> worker_c
etc..
On the other side, another configuration table tells mod_jk which are the Tomcats which it
can use as "workers", to generate responses.
That is the table built from "workers.properties", and it looks like this :
worker_a -> host, port, type, etc..
worker_b -> host, port, type, etc..
worker_c -> internal (to mod_jk)
..
Now, in your Apache configuration, you have these JkMount's :
JkMount /myapp worker_a
JkMount /status worker_c
JkMount /yyy worker>_b
So mod_jk will build it's mapping table accordingly (see above).
When there is a mismatch between the JkMounts (and the "workers" which they mention), and
the contents of "workers.properties" table (which lists the effective workers), then you
get the above error messages.
For example, when the line
JkMount /status jk-status
does not find any corresponding active "jk-status" worker in workers.properties.
So you have a choice :
- if you do have an application under Tomcat (or mod_jk itself) which can handle such
URI's, and you actually want to make this application available, then leave the JkMount,
but enable the corresponding worker in workers.properties.
OR
- if you are not interested in handling these URI's, then remove the
corresponding JkMount
To be complete, and despite the above summary explanation, I should mention that the
"status worker" is a bit of a special case : that /is/ actually a "worker" which is in the
code of mod_jk itself, and the corresponding requests are handled directly by mod_jk,
without forwarding them to an application running under Tomcat.
And the same, in a way, can be said about the "load balancing worker" (lb) : that is an
embedded mod_jk worker. It does not generate responses by itself however : it decides
which "normal" worker should handle this request, and passes it on to that normal worker.
Does that make things clearer ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
