Repository navigation
Detected Oracle Driver stuck during Statement initialization #145
Description
Hello,
I get the error message above regularly after two or three succesfull testings.
Then I have two or three unsuccesful tries with the Oracle Driver stucks, after that in the next try can be succesfull again.
There is no unpredictability if the driver stucks or not.
So we have
30-Apr-2019 15:20:52
30-Apr-2019 15:20:52 C:\Users\vmwareadmin\bamboo-agent-home\xml-data\build-dir\SWITEGIT-WT-JOB1>utplsql run UNITTEST/P6YkF-k4il83_0s@AGTEST -p=UNITTEST.UT_PKG_AUSW_HP_SCHAEDEN -f=UT_JUNIT_REPORTER -o=C:\Users\vmwareadmin\bamboo-agent-home\xml-data\build-dir\SWITEGIT-WT-JOB1\UNIT_TEST_AGTEST_30-04-2019.xml
30-Apr-2019 15:20:52 ###################### utPLSQL cli #######################
30-Apr-2019 15:20:52 # #
30-Apr-2019 15:20:52 # utPLSQL-cli 3.1.6.local #
30-Apr-2019 15:20:52 # utPLSQL-java-api 3.1.6.411 #
30-Apr-2019 15:20:52 # Java-Version: 1.8.0_201 #
30-Apr-2019 15:20:52 # ORACLE_HOME: C:\oracle\product\12.2.0\client_1_x64 #
30-Apr-2019 15:20:52 # NLS_LANG: null #
30-Apr-2019 15:20:52 # #
30-Apr-2019 15:20:52 # Thanks for testing! #
30-Apr-2019 15:20:52 # #
30-Apr-2019 15:20:52 ##########################################################
30-Apr-2019 15:20:52
30-Apr-2019 15:20:53 HikariPool-1 - Driver does not support get/set network timeout for connections. (Nicht unterstützte Funktion: getNetworkTimeout)
30-Apr-2019 15:20:53 Use connection string jdbc:oracle:oci8:/@AGTest
30-Apr-2019 15:20:53 Successfully connected to database. UtPLSQL core: v3.1.2.2134
30-Apr-2019 15:20:53 Oracle-Version: 12.2.0.1.0
30-Apr-2019 15:20:53 Running tests now.
30-Apr-2019 15:20:53 --------------------------------------
30-Apr-2019 15:20:53 TestRunner initialized
30-Apr-2019 15:20:53 Running on utPLSQL v3.1.2.2134
30-Apr-2019 15:20:53 Initializing reporters
30-Apr-2019 15:20:55 Detected Oracle driver stuck during Statement initialization
I tried to experiment with different Clients and Java Versions but as it is said here in the other issues, there is not much scope for experiments while we have to use
Oracle Client 12.2 with jdbc 8 for the 3.1.6 Version of the utPLSQL-cli.
Since it's actually working and it's also the correct configuration I wonder what I can do to become more stability in the testings.
Perhaps I can send you a debug file of a failed test or you can suggest some better working versions of the ojdbc8.jar or the orai18n.jar ( both from 22.02.2019 ) ?
Greetings from Hannover, Germany !
Activity
pesse commentedon Apr 30, 2019
Hi @DrErique
what happens after the
Detected Oracle driver stuck during Statement initialization?The expected behavior would be that CLI does an automatic retry (and potentially some error stacks are written). Does this happen?
It's a problem we investigate since several months now and our solution (because it is very likely to be a driver bug) was to have an internal watchdog which detects such stuck scenario and does up to 5 retries. In that case the outcome of your tests wouldn't be changed, the only thing that happens is that the previous connection is abandoned and a second one is started.
Also: what would be your expectation how CLI deals with such a scenario?
Cheers,
Samuel
P.S. If you happen to be at ApexConnect in Bonn next week, make sure to say hello :)
DrErique commentedon Apr 30, 2019
pesse commentedon May 3, 2019
Hm, this is strange - the Stuck is detected but it's not aborted (for whatever reason).
Can you try a different OJDBC driver?
I use ojdbc8-12.2.0.1.jar currently.
DrErique commentedon May 3, 2019
DrErique commentedon May 8, 2019
Hello Samuel,
Unfortunately that didn't solve the problem.
Do we have any debug option ?
You mentioned the –d Parameter in another issue ?
What about this "HikariPool-1 - Driver does not support get/set network timeout for connections. " report. Perhaps we have a problem with the HikariCP ?
pesse commentedon May 9, 2019
Yeah, this line is strange - didn't notice it so far in any of my runs.
Did you use the latest version of cli from the github page? (yes, there's still something wrong with putting the build number into the version automatically)
DrErique commentedon May 9, 2019
dmpe commentedon May 10, 2019
Hi,
I am also facing same issue here with Oracle DB 11.2,Java-Version: 1.8.0_212 , latest utPLSQL-cli 3.1.6 and jdbc 6 (the one from oracle site)
Actually I wanted to file a request for allowing to specifying more HikariConfig options, i.e.
addDataSourceProperty(e.g. allowPoolSuspension)...maybe it would help slightly to debug the problem ("enterprise configurations")I should also add that utPLSQL 3.1.2 was working well (as expected) - Hikari update ....
EDIT: so using jdbc8 --the one for 12c on the database 11.2; instead of jdbc6 for 11.2), error has changed to .... This is also retried 4 times. I wonder if it has really something to do with Hikari, e.g brettwooldridge/HikariCP#198
pesse commentedon May 13, 2019
For we don't necessarily need a connection pool, I'll try to remove HikariCP completely.
dmpe commentedon May 13, 2019
ok, that sounds awesome if it can be done. Actually I wanted to build several versions of utplsql-cli with different HakariCP and jdbc drivers to test it out where the problem may be. i would try to report my results on this friday...though do no wait on me, just go ahead.
EDIT:
@pesse ok. so i have just tried 2 recent versions of utPLSQL with different versions of Hakari and jdbc
For utPLSQL 3.1.6 code base:
Hakari 2.7.9 and 3.3.1 did not work
For utPLSQL 3.1.2 code base:
Hakari 2.7.9 and 3.3.1 did not work
what works is only 2.7.2 version with this codebase, with jdbc7.
guicampos commentedon Jun 5, 2019
I had a similar issue:
UtPLSQL core: v3.1.6.2735
Oracle Database 12.1.0.2
utPLSQL-cli 3.1.6.local
utPLSQL-java-api 3.1.6.411
Java-Version: 1.8.0_211
ojdbc7.jar
When i first executed the command:
../utPLSQL-cli/bin/utplsql run -d user/passwd@mydb:1521/mysid -source_path=sources -test_path=tests -f=ut_documentation_reporter -c -f=ut_coverage_sonar_reporter -o=coverage.xml -f=ut_sonar_test_reporter -o=test_results.xml --failure-exit-code=0The command hanged for sometime with
After a quite long wait time, and every time it retried the warning was reissued
after the 4th attempt the test runned smoothly:
And now there's no more wait time in new executions.
I'm sending my current debug output, maybe it can help solving it.
and Hey! utPLSQL is awesome!
utplsql-cli-log.txt
pesse commentedon Jun 27, 2019
Hey @DrErique @dmpe @guicampos
could you try out the latest cli and tell me if you still experience the stuck problems?
https://bintray.com/utplsql/utPLSQL-cli/download_file?file_path=utPLSQL-cli-develop-201906272140.zip
DrErique commentedon Jun 28, 2019
19 remaining items
rafael-trevisan commentedon Jun 29, 2020
rafael-trevisan commentedon Jun 29, 2020
I did a test using the OJDBC8 from Oracle website and the message was a bit more verbose:
rafael-trevisan commentedon Jun 29, 2020
Again, the issue is intermittent. If I just re-run the job to re-execute the tests is may pass - or not.
pesse commentedon Jun 30, 2020
Hey @rafael-trevisan , could you attach the full logs of a failing run with
-d(for extensive debug messages)?This looks different to the original stuck statement error.
rafael-trevisan commentedon Jul 23, 2020
Here is it @pesse
rafael-trevisan commentedon Jul 23, 2020
I can see a strange pattern between these failures and around 4 sessions (all from
JDBC Thin Client) getting stuck while running the following command:Every time utPLSQL retries "Retrying (n)" I can see another 3 new sessions running the same funny
select. The wait event for these sessions isPL/SQL lock timer🤔Once utPLSQL finally fails, the sessions will be still "Active" for around 2 or 3 minutes.
rafael-trevisan commentedon Jul 23, 2020
Ha! The number of hanging session is directly related to the number of reports I am generating in my tests!
In my case, I am using the following reports:
Another interesting finding is that I have only 1 report, I get the error once let's say every 10 times I run. With the 3 reports altogether I get the error every 2 or 3 times. Hope that makes sense and helps narrow down this nasty bug.
tplazaro commentedon Dec 14, 2020
Is there any update on this one, any workaround? I'm having the same issue :(
pesse commentedon Dec 14, 2020
This issue is very likely an Oracle bug and highly related to your used Oracle database, used driver etc.
Please provide
pesse commentedon Jan 27, 2021
@rafael-trevisan @tplazaro can you try the steps mentioned in http://github.com/utPLSQL/utPLSQL/issues/1121?
Either access the file
$JAVA_HOME/jre/lib/security/java.securityand changesecurerandom.source=file:/dev/randomtosecurerandom.source=file:/dev/urandomOr set up JAVA_TOOL_OPTIONS:
export JAVA_TOOL_OPTIONS='-Djava.security.egd=file:/dev/./urandom -Dsecurerandom.source=file:/dev/./urandom'pesse commentedon Jan 28, 2021
After sleeping over it I have little hopes this is the problem source (I'm actually quite convinced it's not)
I would still love to get some feedback from you folks, since this is something I cannot test/reproduce myself.
dmpe commentedon Jan 28, 2021
Hi, I am sorry but cannot test it anymore :(
OsBlaineOra commentedon Jul 15, 2021
I am unable to run any code coverage reporter from the cli 9/10 times.
Switching back to running project based coverage through a .sql script requires that I list out every file to be checked. (Unless I'm wrong about that).
Here's how I'm running it from .sql
Create a .sql script to run coverage for corbertura and sonar. (If you're not using sqlcl, remove the !rm... lines)
utplsql_coverage.sql
My source files are in source/plsql, my tests are in tests/utplsql
Create an env for my source and test list.
Run the script
I can use this in my CICD pipeline until we can find a fix for the stuck problem.
jgebal commentedon Sep 27, 2026
Closing as removal of connection Hikari connection pool in #158 seem to fix it