|
Hello, I am running SA v17 High Availability (Primary, Mirror and Monitor servers) on an Ubuntu box and for several years I have used Red Hat's Wildfly Java app server to connect to it. (Normally, the servers would be on separate systems but for troubleshooting, as I did last time, I have them all on the same system.) I originally had problems getting things set up on the Ubuntu system and one problem I had was getting an "Invalid ODBC handle" error. Here's the link to that earlier problem - https://sqlanywhere-forum.sap.com/questions/31996/why-am-i-getting-invalid-odbc-handle-when-using-sajdbc4 I finally got things running and all was well for several years but I have just had to update to Wildfly 20 and I am amazingly getting the same "Invalid ODBC handle" error as I try to configure Wildfly 20 to communicate with the exact same SA 17 server. This time I am pretty sure that I have the sajdbc4 driver and supporting files configured correctly because I have a simple Java app that I can run on the system where Wildfly 20 is installed (Ubuntu 20) and it can connect to and fetch data from a test db running on the SA 17 server. Here's what that looks like: cd $HOME/Desktop export LD_LIBRARY_PATH=/opt/wildfly-20.0.1.Final/modules/system/layers/base/com/sybase/main export CLASSPATH=.:/opt/wildfly-20.0.1.Final/modules/system/layers/base/com/sybase/main/sajdbc4.jar java sajdbc4DriverTest.java ... I see rows from a table in TestDB ... So, I think I have the driver set up correctly. My question is how can I determine what the SA 17 server is doing and responding with when Wildfly tries to connect? I am assuming that Wildfly is not properly handling my Connection String and I hope that there is a log I can get from SA 17 showing me exactly what is being sent by Wildfly and how SA 17 is responding. Here is the Connection String: jdbc:sqlanywhere:Host=192.168.1.45:19000,192.168.1.45:19001;ServerName=TestDB Again, how can I see what SA 17 is receiving and is sending back? Thank you. |
|
For a service the LD_LIBRARY_PATH=/home/myuser/wildfly-20.0.1.Final/modules/system/layers/base/com/sybase/main must be placed in the wildfly.conf file. |
|
Thank you to both Chris and Robert for the additional info! Here's what I've learned The problem is that while I am setting LD_LIBRARY_PATH prior to starting Wildfly that setting is being ignored. I have been running Wildfly as a service and that is where the problem happens. If I start Wildfly manually my LD_LIBRARY_PATH is respected and all of the driver files are found and Wildfly can connect to SQL Anywhere. So, as a stop-gap I'll start the server manually and "on the side" try to figure out why Wildfly as a service is ignoring my LD_LIBRARY_PATH. Thanks again for your help! Perhaps Wildfly as a service doesn't have the right to read from LD_LIBRARY_PATH.
(29 Aug '20, 09:46)
Breck Carter
Hi Breck, No, that's not the problem - it's that I need some different way to get that set. Setting LD_LIBRARY_PATH tells the JVM where to look when searching for the sajdbc4 libraries so I have to get it set. When I finally figure that out I'll post the answer back here for hopefully anyone else trying to access S!L Anywhere from Wildfly to find. Thanks!
(31 Aug '20, 14:39)
AlK
Replies hidden
I'm sure your setting of LD_LIBRARY_PATH is fine... but how do you know the account used to run the service is able to (a) see and (b) read the contents?
(31 Aug '20, 15:39)
Breck Carter
|
|
I can't comment on the particular OS and configuration - but generally you can "debug" the connecting process on both sides via
Hi Volker. Thank you for the info!!! This is what I need. However, neither is generating anything. Here is my modified Connection String: jdbc:sqlanywhere:Host=192.168.1.45:19000,192.168.1.45:19001;ServerName=TestDB;Log=~/Desktop/SAConn.log Can you confirm that is correct syntax and that the file is created on the SA server machine (and not the client/Wildfly machine). Either way no log is being created. I also set the DebuggingInformation property for the HA servers by connecting to the TestDB using iSQL and issuing the call. Again, would you confirm that this would write to the same log that I set up with the -o option when I launched the HA servers? If I have done and understood correctly your suggestions how would you interpret that the SA HA servers are not logging anything. Can we conclude that SA is not even receiving a request (and therefotre Wildfly is not even sending one)? Recall, I can run a simple Java app on the Wildfly machine that is able to connect and fetch data from a table so the SA servers are accessible and responding (I can get to those tables with SQL Central from a third machine as well). Please speculate on what the lack of any server entries might mean and again thanks for your help!
(26 Aug '20, 15:42)
AlK
Replies hidden
1
The LOG connection parameter is used correctly, but note, this is a client connection string, so by design the log file path is relative to the client machine, not to the server. (And that's very reasonable - if the client cannot successfully connect, how could the server log that?) - I can't tell whether the log file path is fitting. So you might check whether a log was written on the client machine.
Yes, that should write to the console and the -o console.log. I would suggest to use the same logging options with your working sample Java app to see what logging entries that does produce, and then compare this with your real app.
(27 Aug '20, 03:54)
Volker Barth
Hi Volker, I have no idea why I asked you to confirm that LOG= created on the server! Yes, that should be on the client and using your great idea to add it to my simple test app shows the log being created. Thanks for that idea. However, I get no log created when I try to connect through Wildfly 20's "Test Connection". I realize that (I believe) you have no experience with Wildfly, but can you speculate on what you would conclude if you saw no log being created (using the exact same Conn String as in the test app)? Do you think it's safe to conclude that for some reason Wildfly is not even attempting a connection and just displaying a misleading "Invalid ODBC Handle"? Thanks again for the help.
(27 Aug '20, 12:48)
AlK
1
It is more likely a symptom of a configuration issue. Have you sourced SQLA in the environment that Wildfly is running? Between the error reported and that the LOG is not being created, it appears that one or more native libraries used by the SQLA jdbc driver native is not being loaded correctly. In addition to the SQLA JDBC driver jar file, Wildfly will need to be able to find and load the following libraries: libdbjdbc17.so.1 libdbtasks17_r.so.1 libdbicu17_r.so.1 libdbicudt17.so.1 libdbrsa17_r.so.1 dblg[LL]17.res These should be located either in a location defined in LD_LIBRARY_PATH, java.library.path, or perhaps a Wildfly specific mechanism.
(27 Aug '20, 23:15)
Chris Keating
1
Using the native drive on macOS, the error you mention had in my environment always to do with what Chris says – sourcing the SQLA in the environment you are using. For example, to be able to connect to SQL Anywhere 17 from within the Eclipse IDE, I have to start Eclipse with a shell script containing the following 2 lines: . /Applications/SQLAnywhere17/System/bin64/sa_config.sh open -a /Applications/Eclipse.app or, using Tomcat, I have to make sure, in a Tomcat launch daemon shell script (for example tomcat-launchd.sh), that sourcing like # Run sa_config.sh to make additionally needed native JDBC driver library files accessible . /Applications/SQLAnywhere17/System/bin64/sa_config.sh is done before #echo "Starting Tomcat" . $CATALINA_HOME/bin/catalina.sh start Hope that helps a bit.
(28 Aug '20, 04:09)
robert
|
