cancel
Showing results for 
Search instead for 
Did you mean: 

JDBC receiver error for only 1 server node, other one works fine

Former Member
0 Kudos

Hi Gurus,

here's a strange one I ran into this week. I have a working IDOC-to-JDBC interface in a PI 7.0 system with 1 server node. After I added a second server node to the instance, lots of messages fail. To be exact: Communication Channel monitor shows quite clearly that all the messages processed by server0 are successful, and all the messages processed by server1 fail.

DefaultTrace excerpt (changed the connection string to ensure privacy):

#com.sap.aii.adapter.jdbc.JDBC2XI##com.sap.aii.adapter.jdbc.JDBC2XI.handleDBConnectException(Exception)#J2EE_GUEST#0##n/a##6cde29c3843f11e1c74b00144f8b0e27#XI JDBC2XI[CCO_JDBC_PowerPlant_Inbound/BS_pub_PowerPlant_Inbound/]_11421##0#0#Error#1#/Applications/ExchangeInfrastructure/AdapterFramework/Services/ADAPTER/ADMIN/JDBC#Plain###Accessing database connection 'jdbc:oracle:thin:***;db-qa:1521/db_qa.db.mydomain.com' failed: com.sap.aii.adapter.jdbc.sql.DriverManagerException: Cannot establish connection :    : SQLException: Io exception: Invalid connection string format, a valid format is: "host:port:sid" #

First of all, there's nothing wrong with the connection string, since it works fine on server0. However, it got me thinking that maybe server1 is using the wrong JDBC driver... But I made sure the parameter ConfigurationManager -> rdbms.driverLocation is the same (/oracle/client/11x_64/instantclient/ojdbc14.jar) for both server nodes.

I checked configtool for any parameters that were defined locally by accident (as these would cause differences after adding a server node) but I couldn't find any.

I still think because of the error that maybe server1 is using the wrong JDBC driver, but how can I be sure?

Thanks guys!

-Peter

Accepted Solutions (1)

Accepted Solutions (1)

baskar_gopalakrishnan2
Active Contributor
0 Kudos

Refer this thread and michal's blog.  This might help you to see whether jdbc driver installed and see that test tool shows any version details of it. 

http://scn.sap.com/thread/2119119

Former Member
0 Kudos

Hi Baskar,

thanks for the tip it's an interesting tool, but it doesn't show the information relevant to my issue. Particularly, I'm trying to figure out what's *different* between server0 (where JDBC CCs work) and server1 (where JDBC CCs fail).

I noticed this about the error message above: the connection string doesn't exactly match the one in the IB. The defaultTrace error message says

'jdbc:oracle:thin:***;db-qa:1521/db_qa.db.mydomain.com'

but the actual connection string is

'jdbc:oracle:thin:@db-qa:1521/db_qa.db.mydomain.com'

Notice the defaultTrace replaces the '@' sign with three stars and a semicolon. Is that a clue worth looking into? Is this a locale / encoding issue?

But if so, how could two server nodes on a single instance differ from one another?

thanks to anyone who has the answer!

baskar_gopalakrishnan2
Active Contributor
0 Kudos

You might want to check using visual administrator and navigate up to services and see the jdbc driver installed is seen.  Also check whether server node 1 has any classpath issues that causing not able to access drivers. Usually deployment is successful, it should be visible for both. If you installed the same drivers for both then it shoud not cause this connection error.  Plus error does not show like unknown class or something similar.  Check whether java version anything different for the node 1 compared to node 0. If that so, there could be issue. Because if you use java 1.4 then you can use the same jars for both nodes. If the java version is 1.5 and above those 7.0 compatible jars might not be working. Just throwing at example.

Answers (1)

Answers (1)

iaki_vila
Active Contributor
0 Kudos

Hi Peter,

Pay attention to the 3 question in this sap note 1000528

What is your SAP PI 7.0 patch level?

Have you look this document http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f071ff6d-5bfb-2910-a985-86ac9f6ad...?

In the 29 page speaks about Maximum concurrency of JDBC messages in a parallel or cluster node.

Regards