tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 47121] mod_jk 1.2.27 produces "JkWorkersFile only allowed once" on Netware 6.5
Date Mon, 25 May 2009 18:32:53 GMT

--- Comment #7 from Guenter Knauf <>  2009-05-25 11:32:48 PST ---
Hi Vladimir,
(In reply to comment #6)
> I do not believe it matters which specific .NCFs I used as long as Apache and
> Mod_JK were unloaded in all Address Spaces and they were.
In fact it does: you use something which sounds for restarting - but if you try
a restart, and Apache is not loaded (because you stopped it) then the shutdown
command starts Apache instead of shutting down, and the following load command
gives you then the 'already loaded' - makes sense? Therefore please use only
the NCFs I suggested, even if these need two steps: first a down followed by an
up; anyway you cant do a restart since you intent to load a new build of a
> I unloaded Tomcat as well just to be on the safe side.
> Next time I can skip that step.
correct, not needed.

> Before I go ahead and run the same experiment again can you please confirm that
> you noticed the difference in 2 IF statements.
yes, and I explained in detail how it works. Please re-read my last comment
where I stated that the block in QFTomcatConnector.conf only is active when
mod_jk is _NOT_ loaded.

> Condition checked is the opposite. Shouldn't it be the same?
No, and I explain again. In httpd.conf you can find:

# The following line instructs Apache to load the jk module
LoadModule jk_module modules/mod_jk.nlm
<IfModule mod_jk.c>
   JkWorkersFile "sys:/adminsrv/conf/mod_jk/"
   JkLogFile "logs/mod_jk.log"
   JkLogLevel error

that means: mod_jk gets unconditionally loaded, and the following block gets
conditionally active when mod_jk is loaded.

In QFTomcatConnector.conf you have:

<IfModule !mod_jk.c>
   LoadModule jk_module modules/mod_jk.nlm
   JkWorkersFile "sys:/adminsrv/conf/mod_jk/"
   JkLogFile "logs/mod_jk.log"
   JkLogLevel error

that means: this block gets only active if mod_jk is _NOT_ already loaded, and
is then loaded, and its config stuff is set.

Now the problem is this:
if QFTomcatConnector.conf is included in httpd.conf _BEFORE_ mod_jk gets loaded
from httpd.conf then the whole block in QFTomcatConnector.conf gets active, and
loads mod_jk + sets JkWorkersFile. Then a bit later comes the unconditional
load of mod_jk from httpd.conf which just gets ignored by the Apache loader
with 'module already loaded', then follows the mod_jk config block which
conditionally gets active when mod_jk is loaded -- and at this time its loaded,
and there then happens the second JkWorkersFile setting which then makes mod_jk
refuse loading.

Now if you just move the include of QFTomcatConnector.conf down _AFTER_ the
mod_jk configure block everything is fine - then mod_jk is loaded already when
QFTomcatConnector.conf is processed, and no second config happens.

I agree that Novell's config is somewhat crazy, and even more worse is that
they then dont care about the order things happen, and where to include
QFTomcatConnector.conf from httpd.conf; though the change we did with mod_jk is
fully correct - realize that with the old behaviour you would never get aware
of a second JkWorkersFile usage, and if it would point to another file than the
standard you would be lost.
Feel free to open a bug report at Novell and tell them they should use same
config block as what they use in QFTomcatConnector.conf - then it wouldnt
matter if mod_jk gets loaded + configured either from QFTomcatConnector.conf,
or from httpd.conf, and there would never happen a second configure; the first
one would just win! Though I doubt it makes much sense to tell Novell for two
1.) I've heard that they stopped working on SP9, so anyway we probably dont get
any updates anymore from Novell.
2.) The whole webservice stuff including mod_jk support is moved to Novell
India, and asked Rainer and me last time for SP8 already about the new stuff
with mod_jk later 1.2.23, and AFAICT they couldnt make sense of our replies -
so they backported some patches so they could avoid later versions.


Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message