Gregor S. wrote:
Hi Chuck!
On Thu, Dec 15, 2011 at 5:36 PM, Caldarale, Charles R
<chuck.caldar...@unisys.com> wrote:
From: Gregor S. [mailto:rc4...@googlemail.com]
Subject: Re: path used for tc-natuve
I guess it's a bad idea to run two different versions
of Tomcat on the same box.
??? Clearly that's not true - it's done all the time. Much easier when not
using these 3rd-party repackaged corruptions...
Hm, maybe my view is too limited, but I really can't see any good
reason running two different versions on the same box.
What's the user-story behind this configuration?
Actually, it is like this : my company is, among other things, hosting application servers
on behalf of others. Think Amazon or Google, just a bit smaller. Quite a bit smaller in
fact. Ok, 0.00001 times smaller or so.
Anyway, we have a Linux server which we host on behalf of a software & services company,
for the ultimate benefit of one of their customers. This server runs Tomcat 5.5, also as a
small intermediate component between the user's workstation and the final application,
wich itself runs under a separate software.
Recently, there have been some communications issues between the workstations and the
application, with both mod_jk and Tomcat 5.5 indicating some errors in their respective
logs. And the software company searched Google and found some indications that a more
recent version of Tomcat might help alleviate the issue, and could we please install a
Tomcat 6.0 on this machine to verify if that's true.
The idea being to be able to temporarily switch just between Tomcat 5.5 and Tomcat 6.0, to
see if the problem disappears, but be able to switch back to Tomcat 5.5 quickly if it does
not or gets worse.
Being the helpful people that we are, we set things in motion immediately to satisfy our
customer.
The software running on that system is installed entirely using the Debian software
package manager (dpkg, apt and consorts). And for that version of Linux, there is no
Tomcat6 package available. Never mind, according to Plan B we downloaded and installed an
official Tomcat from the website. However, when we switched over to that Tomcat6, it
started producing ugly messages in the log indicating that the tc-native version that it
found was outdated, and that it needed at least version so and so.
Which was traced to the fact that it was finding the tc-native library installed by the
Tomcat 5.5 package, in /usr/lib, and not liking the looks of it.
We cannot de-install Tomcat 5.5 nor its older tc-native.
So I was looking for a way either to just stop Tomcat 6 from looking for tc-native, or of
installing the appropriate tc-native somewhere where Tomcat 6 would find it, along
whatever path it is looking for it, prior to the old version in /usr/lib.
With help from the list, I managed to stop it looking for tc-native, by disabling the
<Listener> in server.xml. That made at least the ugly message disappear, and for a test it
is ok to run with the standard Java-based socket stuff. Plan C is thus succesfully
implemented and everyone is happy, except me.
This left me intellectually unsatisfied, because I still did not know how Tomcat6 was
finding this old tc-native, and there is nothing really obvious in the documentation which
explains where it is looking. (Probably because to Real Java Programmers, this is too
obvious; but I am not a Real Java Programmer).
So that's where this very Tomcat list comes in handy again.
Through the information obtained on it, I think I have learned
- that I can compile tc-native if I just have OpenSSL installed on the system
(which I have)
- that if I do compile tc-native and install the resulting tc-native library in the
(CATALINA_HOME)/bin directory of Tomat6, it should use it , by preference to the one in
/usr/lib.
I still don't know exactly why though, and this lack of knowledge is just
killing me.
I should add, because it seems to have a bearing here, that this Tomcat6 is started by a
script in /etc/init.d copied and adapted from the one for Tomcat5.5, which means that it
actually runs under the jsvc wrapper.
That may influence how the search for the tc-native library is effected, and I may have to
to do something to tell jsvc to look in the (CATALINA_HOME)/bin directory of Tomat6 first.
Or not, because as mentioned above, I have no idea really how this all works.
And finally, according to other recommendations on the list which appear to be worthy of
trust, I believe that if, in the script which starts Tomcat6, I would add something like
export LD_LIBRARY_PATH=/opt/tomcat6/bin:$LD_LIBRARY_PATH
that might do the trick as far as tc-native is concerned.
But when I examine the environment of the running Tomcat5.5, it does not seem to have
LD_LIBRARY_PATH defined, so I am puzzled again.
So let me make a partly-educated guess, and someone here can tell me how far off the mark
I am.
Tomcat6 is Java code, so when it looks for a library, it actually asks the JVM
to find it.
The JVM is native code, so it looks along it's own "library path" to find the desired
module. (*)
But the JVM being wrapped by the jsvc wrapper, it falls down to the jsvc wrapper to look
along its own library path for the module, in an attempt to satisfy the JVM. (**)
And when native code under Linux is looking for a library, this is probably done through
some other standard library providing "library loading" functions.
And this "library loading library" probably looks first at which search path is contained
in the LD_LIBRARY_PATH variable, prior to searching in some other path provided in it's
own configuration data.
(*) but maybe Tomcat has told it to look first in CATALINA_HOME/bin ?
(**) or maybe jsvc does not intervene at all, and it is the JVM which talks directly to
the "library loading library" ?
(And I am quite sure that the way I am guessing above is going to make some Real
Programmers cringe, and wonder how I have been able to survive for 30+ years in this world
not knowing this kind of stuff.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
