tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: path used for tc-natuve
Date Thu, 15 Dec 2011 18:15:15 GMT
Gregor S. wrote:
> Hi Chuck!
> On Thu, Dec 15, 2011 at 5:36 PM, Caldarale, Charles R
> <> wrote:
>>> From: Gregor S. []
>>> 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 
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
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 

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:
For additional commands, e-mail:

View raw message