Detected Oracle Driver stuck during Statement initialization #145
Comments
|
Hi @DrErique what happens after the Also: what would be your expectation how CLI deals with such a scenario? Cheers, P.S. If you happen to be at ApexConnect in Bonn next week, make sure to say hello :) |
|
Hello Samuel,
Thanks for the quick response.
As you probably have noticed the utPLSQL Command starts from a Bamboo – Powershell – Skript – Task.
I do not notice any retry .
Last entry in the Log is "Detected Oracle Driver stuck …" and the build runs endless until it is stopped manually.
As you can see in the picture the build ran for 21 minutes.
Maybe I have to set some special parameters for the retries ?
As you already found out retrying the connection for 1 – n times is the only thing you can offer in such cases.
But in my case ist seems there is nor real retrying happening ….
[cid:[email protected]]
Mit freundlichen Grüßen
Derik Wehrmann
…_________________________________________________________________
Tel: -551 | Test- und Qualitätsmanager | IT SCM und Support
Von: Samuel Nitsche <[email protected]>
Gesendet: Dienstag, 30. April 2019 16:04
An: utPLSQL/utPLSQL-cli <[email protected]>
Cc: Wehrmann, Derik <[email protected]>; Mention <[email protected]>
Betreff: Re: [utPLSQL/utPLSQL-cli] Detected Oracle Driver stuck during Statement initialization (#145)
Hi @DrErique<https://github.com/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 :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#145 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIPTY43SEIDGFHTFQWDVQA3PTBGWPANCNFSM4HJLZYZA>.
|
|
Hm, this is strange - the Stuck is detected but it's not aborted (for whatever reason). |
|
Hello Samuel,
I'll get that one and we see if this works better next week.
Have a nice weekend !
Mit freundlichen Grüßen
Derik Wehrmann
…_________________________________________________________________
Tel: -551 | Test- und Releasemanager | IT SCM
Von: Samuel Nitsche <[email protected]>
Gesendet: Freitag, 3. Mai 2019 10:55
An: utPLSQL/utPLSQL-cli <[email protected]>
Cc: Wehrmann, Derik <[email protected]>; Mention <[email protected]>
Betreff: Re: [utPLSQL/utPLSQL-cli] Detected Oracle Driver stuck during Statement initialization (#145)
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#145 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIPTY44UZUODUCVDHWFEV4TPTP4UPANCNFSM4HJLZYZA>.
|
|
Hello Samuel, Unfortunately that didn't solve the problem. 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 ? |
|
Yeah, this line is strange - didn't notice it so far in any of my runs. |
|
I'll try that also, downloading latest version.
We see if this works better … ☺
Von: Samuel Nitsche <[email protected]>
Gesendet: Donnerstag, 9. Mai 2019 09:24
An: utPLSQL/utPLSQL-cli <[email protected]>
Cc: Wehrmann, Derik <[email protected]>; Mention <[email protected]>
Betreff: Re: [utPLSQL/utPLSQL-cli] Detected Oracle Driver stuck during Statement initialization (#145)
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)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#145 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIPTY426DNC4Z4JRGNBDL4TPUPGQ5ANCNFSM4HJLZYZA>.
|
|
Hi, Actually I wanted to file a request for allowing to specifying more HikariConfig options, i.e. 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 |
|
For we don't necessarily need a connection pool, I'll try to remove HikariCP completely. |
|
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: 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 |
|
I had a similar issue: UtPLSQL core: v3.1.6.2735 When i first executed the command:
The 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! |
Merged
|
Hey @DrErique @dmpe @guicampos |
|
Hello Samuel,
Thanks for contacting.
I'll try some builds with that next week and tell you about the results.
Nice weekend !
Mit freundlichen Grüßen
Derik Wehrmann
…_________________________________________________________________
Tel: -551 | Test- und Releasemanager | IT SCM
Von: Samuel Nitsche <[email protected]>
Gesendet: Donnerstag, 27. Juni 2019 23:49
An: utPLSQL/utPLSQL-cli <[email protected]>
Cc: Wehrmann, Derik <[email protected]>; Mention <[email protected]>
Betreff: Re: [utPLSQL/utPLSQL-cli] Detected Oracle Driver stuck during Statement initialization (#145)
Hey @DrErique<https://github.com/DrErique> @dmpe<https://github.com/dmpe> @guicampos<https://github.com/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
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#145?email_source=notifications&email_token=AIPTY44HQ6ISYACF6PY3HCDP4UYTTA5CNFSM4HJLZYZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYYPEEQ#issuecomment-506524178>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIPTY44MEWJIDLG6DYQN34LP4UYTTANCNFSM4HJLZYZA>.
|
Thanks for the effort!!! |
|
Is this the complete log of the problematic run?
Am Fr., 28. Juni 2019 um 16:07 Uhr schrieb John <[email protected]>:
… Use connection string jdbc:oracle:thin:
Successfully connected to database. UtPLSQL core: v3.1.1.1868
Oracle-Version: 11.2.0.4.0
Running tests now.
--------------------------------------
TestRunner initialized
Running on utPLSQL v3.1.1.1868
Initializing reporters
Detected Oracle driver stuck during Statement initialization
Timeout while waiting for reporters to finish for 60 minutes
Thanks for the effort!!!
It is better now but getting some errors. unfortunately cannot debug this
today more extensively. Only later in the month.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#145?email_source=notifications&email_token=AB7ZXYH4SQ4LMUCDDFFK6S3P4YLI5A5CNFSM4HJLZYZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY2FREA#issuecomment-506747024>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB7ZXYEY2KYYRGQIGUCLMB3P4YLI5ANCNFSM4HJLZYZA>
.
|
|
Yes. I have just deleted login info EDIT: I have used |
|
Thank you for trying out.
I'm a bit lost on this, but will try to work my way around it.
I might create a new, dedicated issue for that.
Am Fr., 28. Juni 2019 um 16:09 Uhr schrieb John <[email protected]>:
… Yes. I have just deleted login info
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#145?email_source=notifications&email_token=AB7ZXYBFPPJYWX2O555HA3TP4YLQZA5CNFSM4HJLZYZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY2FWUI#issuecomment-506747729>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB7ZXYA7PAOHF5XTKJS3BNLP4YLQZANCNFSM4HJLZYZA>
.
|
|
Hello Samuel,
Good news.
The first couples of tests with the Bamboo Pipeline were successful.
The client was able to hold the connection to the Database for a duration of 20 – 30 Minutes without getting stucked or other problems.
I am very hopeful that we can establish firmly connections to the database with the client in the future.
For the first thank you for your work and the kindly conversation.
Mit freundlichen Grüßen
Derik Wehrmann
_________________________________________________________________
Tel: -551 | Test- und Releasemanager | IT SCM
Von: Samuel Nitsche <[email protected]>
Gesendet: Freitag, 28. Juni 2019 16:12
An: utPLSQL/utPLSQL-cli <[email protected]>
Cc: Wehrmann, Derik <[email protected]>; Mention <[email protected]>
Betreff: Re: [utPLSQL/utPLSQL-cli] Detected Oracle Driver stuck during Statement initialization (#145)
Thank you for trying out.
I'm a bit lost on this, but will try to work my way around it.
I might create a new, dedicated issue for that.
Am Fr., 28. Juni 2019 um 16:09 Uhr schrieb John <[email protected]<mailto:[email protected]>>:
Yes. I have just deleted login info
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#145?email_source=notifications&email_token=AB7ZXYBFPPJYWX2O555HA3TP4YLQZA5CNFSM4HJLZYZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY2FWUI#issuecomment-506747729>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB7ZXYA7PAOHF5XTKJS3BNLP4YLQZANCNFSM4HJLZYZA>
.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#145?email_source=notifications&email_token=AIPTY47PQ3K6PQVJ5E3KLHLP4YL27A5CNFSM4HJLZYZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY2F5SY#issuecomment-506748619>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIPTY43UCNGDXCDN4VOJBWDP4YL27ANCNFSM4HJLZYZA>.
|
|
Thanks for reporting back, @DrErique |
|
Hi everyone, Is there any news on this issue ? I have come across the same problem "Detected Oracle driver stuck during Statement initialization" when trying to calculate the coverage: If it's just the run of the tests then it works: Thanks & Regards, |
|
Hi All, I have recently started doing POC on the utPLSQL for using it as a unit test frame work for PLSQL developments. But I am encountering below issue when try executing the test from CLI. Kindly help. |
|
Hey @vasanthsumanath , can you please provide a full log as file, running the cli with the |
|
Just to add, its working fine when connected to a different DB, Below are the major difference between the 2 DB environments Successfully executed in Oracle-Version: 12.2.0.1.0 Failed Executing from |
|
Hi @pesse, Thanks for your quick response, yes will do it. Thanks |
Hi @pesse I have attached log when executed in debug mode. Below the command executed |
|
Any help/suggestion with the issue I am facing? |
|
These issues are among the hardest to investigate, because they are near impossible to reproduce on a different database. My guess from the error message is that it's not really a "Stuck" problem as we have faced it in the past, but some general issue with the driver. What you could do and that would probably help to investigate:
|
|
Hi guys, I've started facing this issue too. I can say it's indeed intermittent and it's likely to happen more often (don't know why) when using the CLI in a pipeline. In my case here I am using GitHub Actions and there are times the test step fails because of this. If I simply hit "re-run jobs" I got cases that it worked on the first re-try and other it took more re-tries to work. If any log is needed or further information that may help troubleshooting this, let me know. |
|
Which Oracle version are you on? Latest patchs applied? Same is true for you as for Vasanthsumanath:
|
|
I am using Oracle SE2 on AWS RDS. I am not sure about where it's in patches but RDS's settings are to upgrade even minor patches. I am not installing any custom version of OJDBC. I am getting the CLI from and I assume it contains the latest OJDBC, am I right? If I want to try different version of OJDBC is it just replacing the existing one shipped with the CLI with whatever version I want to test? |
|
I am not sure if that helps, but when this issue happens I see a couple of sessions for my "testing" user waiting while trying to run: |
|
Can you please issue the following code to give a complete picture what Oracle version you're using? From what I read there are different versions of Oracle DB available on AWS: And yes, you can replace the default one by just replacing the JAR with any other OJDBC driver. |
|
|
I did a test using the OJDBC8 from Oracle website and the message was a bit more verbose: |
|
Again, the issue is intermittent. If I just re-run the job to re-execute the tests is may pass - or not. |
|
Hey @rafael-trevisan , could you attach the full logs of a failing run with This looks different to the original stuck statement error. |
|
Here is it @pesse |
|
I can see a strange pattern between these failures and around 4 sessions (all from Every time utPLSQL retries "Retrying (n)" I can see another 3 new sessions running the same funny Once utPLSQL finally fails, the sessions will be still "Active" for around 2 or 3 minutes. |
|
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. |
|
Is there any update on this one, any workaround? I'm having the same issue :( |
|
This issue is very likely an Oracle bug and highly related to your used Oracle database, used driver etc.
|
|
@rafael-trevisan @tplazaro can you try the steps mentioned in https://github.com/utPLSQL/utPLSQL/issues/1121? Either access the file Or set up JAVA_TOOL_OPTIONS:
|
|
After sleeping over it I have little hopes this is the problem source (I'm actually quite convinced it's not) |
|
Hi, I am sorry but cannot test it anymore :( |
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 !
The text was updated successfully, but these errors were encountered: