We have WM IS with version 9.9 with JDBC Adapter 9.0.
So here we have two nodes A and B where jdbc connection is present in both nodes A/B but a day back when we restarted both WM IS nodes in node A JDBC connection is up and node B we are seeing issue where as it show connection is not enable.
When we try to disable/enable connection in node B it’s not getting enable and throw below exception
[ART.118.5042] Adapter Runtime (Connection): Unable to enable connection resource xyz__Connection.
[ART.118.5063] Adapter Runtime (Connection): Unable to start connection xyz_Connection: after 1 attempt(s).
Could not initialize class oracle.jdbc.pool.OracleDataSource
What I have tried to resolve this issue in B where we have jdbc connection issue>
- restarted both nodes 1 by 1
- replace ojdbc7.jar in node A to B and restarted
- reloaded packages
- deployed connection package from node A to B
- place file in home IS WM/instance/name/lib/jars/ojdbc6.jar and even tried to place jar file in WM/Integration/lib and
WM/Integration/lib/jars and restarted but still not luck
- compared all jars in node A and B
- When I change > JDBC connection >DataSource Class oracle.jdbc.pool.OracleDataSource to some other dataSource class it’s working that is connection is getting enabled but it’s not working with oracle data class
- I have tried to connect this DB connection in DB tool it’s working fine
- we have check IS class path and that also look good
- Exiting JDBC fixes Updates JDBC_9.0_Fix8
- IS 9.9 Linux Server 64 bit
Kindly come back with suggestion to resolve this issue or let me know if you need more information
Please make sure that you only have one ojdbc.jar available in ISes.
Most likely this will be the ojdbc7.jar which only should be located under WmJDBCAdapter/code/jars for the master package repository and the instances packages directory.
Are node A and node B 2 instances under the same installation directory or two different installations?
Are the nodes clustered to each other or not?
Can you provide the full StackTrace for “could not initialize” error?
Latest Fix for the JDBC Adapter 9.0 is currently Fix12.
As per the JDBC installation guide, you must place the .zip or .jar file containing the classes in the Integration Server_directory\instances\instance_name \packages \WmJDBCAdapter\code\jars directory. Restart Integration Server.
Also, there are some fix levels for your JDBC version, kindly check if that helps.
Good to see you back, thanks for taking up this issue need a quick fix on this jdbc connection issue in our uat servers
node a & node b are not in IS cluster, yeah we have uploaded ojdbc7.jar which are located under WmJDBCAdapter/code/jars
is present in master and instance package repository
Yeah node A and node B are 2 instances under the same installation directory but two have two different instances
let says instance node A and instance for node B
In Node A we have same level of fix as present in node B with respect to all components
Find the server logs with resp to connection JDBC issue for your reference.
serverLogsJDBCConnectionIssue.txt (16.8 KB)
Can you pls try to place ojdbc jar in /WmHome/instance/defaul/lib/jars directory only and remove from all other places ?
We are having the same issue. We just installed 9.12 this past week with the JDBC Adapter 9.10 and applied all the available fixes as of monday 3/13. Now we are a cluster environment and a non-clustered environment. nodes A and B are clustered and C is stand alone . A as no issues just like you but B and C neither of them can find the Oracle Class… I did open a ticket with Support this morning with all the info I had (logs, Diagnostics and screenshots) I also mentioned this thread since it seems to be the same issue… If we figure out our issue I’ll make sure update you here and see if it fixes your’s too.
In this case I would prefer /WmHome/instance/defaul/lib/jars/custom.
I agree with Mahesh that you should follow the instructions in the Installation Guide which points out where to place the jars.
Placing the Jars in the Adapter package has the benefit that you only need to reload the Adapter package to activate a new jar.
When placing under /WmHome/instance/defaul/lib/jars it is neccessary to shutdown and restart the complete IS.
More likely there seems to be an issue with the confiiguration of the Connections.
As per the server Logs provided there is an issue while loading/starting the JDBCAdapter.
Unfortunately it does not contain any info why it fails loading the JDBCAdapter. Can you check the Error Log of the IntegrationServer if it contains more detailed informations about that?
Agree with you that we should place the jars at package level so that restart of IS is not required in case of any changes.
But in past i faced same issue…may be in 9.7 and at that time i tried to place jar file everywhere and finally it works for me when i placed the file in /defaul/lib/jar directory. (Not pretty sure about the issue)
We just got both node B and C to work…
We have the jar files in this location
So we had 4 jar files there…
So I removed the ojdbc6.jar and restarted. and our Adapters started working.
So I’m thinking we got Lucky in node A that it was using ojdbc7.jar and then in B and C it must have pulled in the ojdbc6.jar… That is the only thing I can see that happened. So make sure you don’t have both listed. The new version must not always pick the most recent jar file.
Hopefully this helps.
as the order in which the jar files are loaded is not deterministic, it should be avoided to have multiple versions of them in classpath.
Please note that the number in ojdbc6.jar or ojdbc7.jar specifies the JVM version it was build for.
Up to Oracle 11g there was an ojdbc5.jar and an ojdbc6.jar available, for Oracle 12c drivers the ojdbc5.jar was retired and ojdbc7.jar was introduced.
You can find the exact version of the jars in the META-INF/MANIFEST.MF file inside the jar when you open with a zip-compatible program.
orai18n.jar and xdb.jar are optional jars which are not required to connect to Oracle database out-of-the-box except for very rare occasions.
Have you tried restarting IS from <WM_Home>/IntegrationServer/instances/default/bin/startup.sh ?
Even though it is not advised to use this path to restart IS but it is worth trying to narrow down the issue.
We are using 9.9 and have faced similar issue in past when tried to restart IS from Admin Page or /WM_Home/profiles/IS_default/bin/startup.sh
No matter where you place the jar files, IS will search for all of the jar files on start time, not runtime.
The reasoning for their placement depends on their use (from most generic to most specific):
- /common/lib/ext/ if used by several products (IS, MWS, App, etc);
- /IntegrationServer/lib/jars if used by several IS instances
- /IntegrationServer/instances//lib/jars if used by several packages in the same IS instance
- /IntegrationServer/instances//packages//code/jars/static if only used in the package.
The last case is useful when you want to be able to manage a package and its jars as a single unit.
When you remove the package, those files no longer occupy the server’s RAM. (Remember this is not dynamic, you would have to actually remove the package and restart the server, unload alone would not suffice).
As always you can check the IS web admin interface jar list from the top-left “About” page in http:///WmRoot/server-environment.dsp
PS:I have a few doubts about the dynamic behavior of loading and unloading jars in the IS. Can anyone verify the behavior in the latest versions? Has it become more dynamic?
there is a KB Article related to this:
When placing jars under IntegrationServer/lib/jars or IntegrationServer/intsances//lib/jars I would prefer to put them in subdirectory custom to have them separated from the default jars.
Related to the package location:
Not all jars need to be placed in the static subdirectory. This is only required if the jars have a native part like i.e. the SAP JCo jars for SAP Adapter.
When placing jars in the static subdirectory it is required to stop and restart the complete IntegrationServer when ever the jars are changed.
If it is possible to place them in code/jars it is sufficient to just reload the package (and all packages which are declared to be dependent on this one).
This is related on how ClassLoaders are organized by JVM and IntegrationServer.
Can you please come back to my issue, i have very serious issue which has escalated to sag team but still it’s taking time and my customer is not ready wait.
I have tried to reinstalled WmJDBCAdapter package via update manager and cleaned all ojdbc7.jar from all path and replace jar once again via refreshing packages and even have restarted IS multiple times
Even SAG team has suggested to place Fix10 but still it’s didn’t work while my other Node A which is not in IS cluster are working fine with Fix8 for adapter connections. so i have replace my fix 8 back to IS nodea B.
Do we have any more trouble shooting or suggestion to resolve my issue?
please provide the /WmRoot/updates.dsp output for each of your nodes.
For Debugging purposes you can increase the log level for the JDBC Adapter:
In IS Admin UI under Settings → Logging → Server Logger → General → Adapters → JDBC Adapter.
After changing the log level try to restart the connection and see what happens.
Provide us the log afterwards.
Remember to revert the Log Level after debugging is complete to reduce the log file size.
Please have look at the IntegrationServer Clustering Guide as well as at the JDBC Adapter Users Guide for Clustering section.
Issue resolved by placed lower version of ojdbc6.jar in only one place in instance/WmJDBCAdapter/code/jars because ojdbc6.jar is well tie up with Oracle 11g version which we are currently using in our env and after that we have restarted IS, it’s work fine.
They didn’t able to explain why higher version of ojdbc7.jar is not working in our env where as we have other envs and multiple instances there ojdbc7.jar is working fine.
It’s suppose to have backward compatibility but our case it’s didn’t work they tried all trouble shooting steps and at last shoot we just tried by putting lower jar it’s work fine.
I am currenlty using ojdbc7.jar from Oracle 12c 18.104.22.168 driver version wth wM 9.5 and do not encounter any severe problems.
Even when connecting to Oracle 11g 22.214.171.124.
Recommended other version for the jar is ojdbc6.jar from either Oracle 11.g 126.96.36.199 driver or 188.8.131.52 driver.
These jars are available from OTN for download.
Remember when using additional jars like orai18n.jar or xdb.jar that they should have the matching driver version related to the ojdbc.jar.