-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OracleContainer
JDBC connection on startup does not succeed with version 1.16.0 using image oracleinanutshell
#4297
Comments
Hey @smcvb, thanks a lot for bringing this to our attention. I will try to reproduce and investigate this. Note that this image as a never Oracle-XE version and therefore needs to be configured a little bit differently. Therefore, String oracleImage = "gvenzl/oracle-xe";
String password = "foobar";
OracleContainer oracle = new OracleContainer(oracleImage)
.withPassword(password )
.withEnv("ORACLE_PASSWORD", password ) Update: |
Thanks for the recommendation @kiview. Your suggestion works though, so thanks a bunch! |
After some debugging, I found out, that the port mappings look different on GHA. That's how I see them on GHA:
and that's what I have locally with Docker for Windows:
So we can see some additional IPv6 like mappings. Besides this, I could not see a difference in the created container. Besides, I was able to identify #3015 as the PR, that introduced this problem for this image on GHA. Edit:
Also see https://github.com/testcontainers/testcontainers-java/pull/607/files#diff-21b1fe66043572c76c549a4fc5f186e9a69c330b186fc91116b9b70a4d047902R39-R40 for a possible fix for the GHA environment, i.e. by configuring a timezone (this was for CircleCI, but there might be a similar way to configure it in GHA). While I think we should improve the logging for this case, I feel the actual issue at hand is resolved through this analysis and can be mitigated by either using a different image (e.g. |
oracleinanutshell
oracleinanutshell
OracleContainer
JDBC connection on startup does not succeed with version 1.16.0 usingimage oracleinanutshell
OracleContainer
JDBC connection on startup does not succeed with version 1.16.0 usingimage oracleinanutshell
OracleContainer
JDBC connection on startup does not succeed with version 1.16.0 using image oracleinanutshell
Thanks for the information here @kiview. The investigation is much appreciated. |
We have to fallback to v1.15.3 testcontainers, because Azure Pipeline always complaining the following error when starting the container: ``` 04:18:43,894 [main] INFO 🐳 [jark/oracle-xe-11g-r2-cdc:0.1] [] - Waiting for database connection to become available at jdbc:oracle:thin:system/oracle@localhost:49165:xe using query 'SELECT 1 FROM DUAL' 04:18:43,949 [docker-java-stream--1472620850] INFO com.ververica.cdc.connectors.e2e.OracleE2eITCase [] - STDOUT: Starting Oracle Net Listener. 04:18:44,102 [docker-java-stream--1472620850] INFO com.ververica.cdc.connectors.e2e.OracleE2eITCase [] - STDOUT: Starting Oracle Database 11g Express Edition instance. 04:18:58,842 [docker-java-stream--1472620850] INFO com.ververica.cdc.connectors.e2e.OracleE2eITCase [] - STDOUT: 04:22:44,218 [main] ERROR 🐳 [jark/oracle-xe-11g-r2-cdc:0.1] [] - Could not start container java.lang.IllegalStateException: Container is started, but cannot be accessed by (JDBC URL: jdbc:oracle:thin:system/oracle@localhost:49165:xe), please check container logs ``` According to this issue[1], this might be a problem of Oracle testcontainers v1.16 working with "wnameless/oracle-xe-11g-r2". A better solution might be upgrade our Oracle base image to "gvenzl/oracle-xe" which is the default image of Oracle testcontainers v1.16. [1]: testcontainers/testcontainers-java#4297
We have to fallback to v1.15.3 testcontainers, because Azure Pipeline always complaining the following error when starting the container: ``` 04:18:43,894 [main] INFO 🐳 [jark/oracle-xe-11g-r2-cdc:0.1] [] - Waiting for database connection to become available at jdbc:oracle:thin:system/oracle@localhost:49165:xe using query 'SELECT 1 FROM DUAL' 04:18:43,949 [docker-java-stream--1472620850] INFO com.ververica.cdc.connectors.e2e.OracleE2eITCase [] - STDOUT: Starting Oracle Net Listener. 04:18:44,102 [docker-java-stream--1472620850] INFO com.ververica.cdc.connectors.e2e.OracleE2eITCase [] - STDOUT: Starting Oracle Database 11g Express Edition instance. 04:18:58,842 [docker-java-stream--1472620850] INFO com.ververica.cdc.connectors.e2e.OracleE2eITCase [] - STDOUT: 04:22:44,218 [main] ERROR 🐳 [jark/oracle-xe-11g-r2-cdc:0.1] [] - Could not start container java.lang.IllegalStateException: Container is started, but cannot be accessed by (JDBC URL: jdbc:oracle:thin:system/oracle@localhost:49165:xe), please check container logs ``` According to this issue[1], this might be a problem of Oracle testcontainers v1.16 working with "wnameless/oracle-xe-11g-r2". A better solution might be upgrade our Oracle base image to "gvenzl/oracle-xe" which is the default image of Oracle testcontainers v1.16. [1]: testcontainers/testcontainers-java#4297
Within my project, we have a couple of integration tests that use the
oracle-xe
artifact.These integration tests worked fine in version 1.15.3 of that dependency but started failing as soon as we moved to 1.16.0.
The tougher issue is that they (of course) do not fail locally, but only when the build is run from within GitHub Actions.
The exact exception I get is
Caused by: java.lang.IllegalStateException: Container is started, but cannot be accessed by (JDBC URL: jdbc:oracle:thin:system/oracle@localhost:49159:xe), please check container logs
.Although I get the message, I am currently hard-pressed to figure out how to enter the test containers constructed within the test containers of GitHub Actions.
A hint here would be greatly appreciated, as I am confident of finding the predicament there.
We construct the test container through the
OracleContainer
constructor, by the way, pairing this with the@Container
annotation on the field and@Testcontainers
annotation on the integration test class.For completions-sake, here's the complete stack trace:
The text was updated successfully, but these errors were encountered: