views:

1300

answers:

2

I have three machines set up as follows:

  • CompA: Running Oracle server 10.2.0.3
  • CompB: Running Oracle server 10.2.0.4 and my client code
  • CompC: Running client code only

On the client code on both CompB and CompC, connecting to either Oracle DB works flawlessly using the Thin driver.

I am trying to connect to each Oracle DB from the client code through the OCI driver using

Connection conn = DriverManager.getConnection('jdbc:oracle:oci:username/pass@sid');

From inside of a Java class that is running in jboss. This works just fine on CompB, but causes the JVM running Jboss to core dump every time on CompC.

CompC can connect to both Oracle servers using Sql*Plus and the same tnsnames.ora file that jboss is trying to reference.

Here is a portion of the stack trace. It appears to be consistent each and every time.

Stack: [0x30fcc000,0x3101d000),  sp=0x3101a868,  free space=314k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x2d02d6]
C  [libocijdbc10.so+0x585c]
C  [libocijdbc10.so+0x70a8]  Java_oracle_jdbc_driver_T2CConnection_t2cCreateState+0x15c
j  oracle.jdbc.driver.T2CConnection.t2cCreateState([BI[BI[BI[BISI[S[B[B)I+0
j  oracle.jdbc.driver.T2CConnection.logon()V+551
j  oracle.jdbc.driver.PhysicalConnection.(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/util/Properties;Loracle/jdbc/driver/OracleDriverExtension;)V+381
j  oracle.jdbc.driver.T2CConnection.(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/util/Properties;Loracle/jdbc/driver/OracleDriverExtension;)V+10
j  oracle.jdbc.driver.T2CDriverExtension.getConnection(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/util/Properties;)Ljava/sql/Connection;+67
j  oracle.jdbc.driver.OracleDriver.connect(Ljava/lang/String;Ljava/util/Properties;)Ljava/sql/Connection;+831
j  java.sql.DriverManager.getConnection(Ljava/lang/String;Ljava/util/Properties;Ljava/lang/ClassLoader;)Ljava/sql/Connection;+210
j  java.sql.DriverManager.getConnection(Ljava/lang/String;)Ljava/sql/Connection;+15

Does anyone know what's going wrong here?

UPDATE: For clarification, "client", as used above refers to my java code running in a jboss instance. The only Oracle libraries that should be found in the LD_LIBRARY_PATH that jboss is started with are libocijdbc10.so libclntsh.so.10.1 and libnnz10.so. These three libraries and the jboss server itself are in source control, so they are the same versions on both CompB and CompC.

CompB can connect, using OCI and thin, to both CompA and CompB. CompC cannot connect using OCI, but can connect using thin, to both CompA and CompB, so it shouldn't be a server version issue.

Both CompB and CompC are running 32-bit Ubuntu 8.04, though CompC has a slightly slower CPU and only 1GB of RAM, compared to 3.25GB RAM on CompB.

+2  A: 

Well, I just finished watching an episode of House, so let's try a differential diagnosis here. You know that it works with the Thin driver from both machines, but it's expiring in the JBoss code. You don't say for sure ("client" isn't very definite) but it would appear that you have a JBoss instance on CompB and on CompC, and your code runs happily when it runs in the JBoss instance on CompB but core dumps from CompC.

From the setup, I infer that when you run on CompB, you're talking to the Oracle instance on CompB. Have you tried running the code on CompB but talking to CompA? Have you tried running the code on CompC, but talking to the Oracle on CompB?

The actual errors indicate a fault occurring in native code in a dynlib module "libocijdbc10.so" and we know that you have different versions of the Oracle stuff on CompA and CompB. So my first suspicion would be that you have incompatible versions of libocijdbc10.so on the two machines. I observe that you have a different version of Oracle on CompA and CompB. I predict that the code on CompB talking to CompA's oracle will fail, and that the code on CompC talking to CompB will run.

You want to check the versions of the Oracle OCI driver software on CompB and CompC.

Update

Okay, you say:

CompB can connect, using OCI and thin, to both CompA and CompB. CompC cannot connect using OCI, but can connect using thin, to both CompA and CompB, so it shouldn't be a server version issue.

So, you have this narrowed down. Three connection methods (Thin, SQL*Plus, and OCI) and three servers, and the only one that fails is using OCI from CompC; that fails talking to both CompA and CompB.

It follows the problem is a configuration problem on CompC JBoss. It's still failing in the Oracle-supplied driver; since the same code works against CompA and CompB when running on CompB, it has to be a CompC problem, not a problem in your code.

So

  1. run cmp(1) against the driver libraries from CompB and from CompC and confirm they're the same.
  2. when they're not, rcp the drivers from CompB onto CompC and test.
  3. figure out what went wrong with the configuration control.
Charlie Martin
Thanks for taking a stab at this, I added some clarification to the question to answer some of your questions.
Ryan Ahearn
A: 

Just give up on the native OCI driver - it's a never-ending headache.

Use the pure java driver - it's more stable, faster and uses less memory.

by pure java, do you mean the thin driver? I was under the impression that the native OCI driver was needed for RAC clusters. Is that not the case?
Ryan Ahearn