I am running Tomcat 5.5.23 on JDK 1.5.0_12 on Solaris 10.
The webapp, as part of its startup, loads a native library and initializes a pool of connections to Oracle database. However, whenever the webapp starts deploying, the JVM crashes with a core dump. This behavior is erratic and soemtimes the initializations are successful. Another point is when the connection pooling code is commented out, the native library is loaded fine. The webapp is using Oracle Type 4 driver to connect to the database.
Can anyone give me a pointer as to what can possibly be going wrong here? I had a look at the core dump using jstack tool (available with JDK 1.5), but couldn't make out much from the stack traces (I can post it if required).
Hi Tushar, Is the connection pooling code is trying to make too many connection? Please post the threas dump so that we can give more suggestions.
Try running the connection pooling code seperatly and see if its working fine.
Joined: May 03, 2006
There are a few more observations: if the connection pool is initialized before the native library is loaded, I still get a core dump but now the stack traces contain calls to objects which are initialized after the native library. So, I don't think it's related to connection pooling code as such. This may indicate that the native library init calls are corrupting the JVM heap. But, at the same time, when I run the same code as part of a standalone Java app (not in Tomcat), everything works fine.
Following is the latest trace (where connection pool is init before the native library):
======================= JNI Based Applications: ======================= Applications that require native libraries must ensure that the libraries have been loaded prior to use. Typically, this is done with a call like:
in some class. However, the application must also ensure that the library is not loaded more than once. If the above code were placed in a class inside the web application (i.e. under /WEB-INF/classes or /WEB-INF/lib), and the application were reloaded, the loadLibrary() call would be attempted a second time.
To avoid this problem, place classes that load native libraries outside of the web application, and ensure that the loadLibrary() call is executed only once during the lifetime of a particular JVM.