-
Notifications
You must be signed in to change notification settings - Fork 645
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
wait on log ending too fast, would be nice to be able to add some delay #608
Comments
Thanks for the bug report. It sounds a bit strange that the application which starts after the DB startup runs into such a race condition, since the dependent container is to be started only after the database container is up, so there are at least several seconds until a datasource eventually hits the database. Do you have a log trace of the failing case ? (maybe with '-Ddocker.verbose=true' set) Ideally of courrse would be the project (or a stripped down version) itself so that I could reproduce it. BTW, with d-m-p version are you using ? |
Thanks for the feedback, what is d-m-p? Oh, maybe I forgot to mention, normally it is okay on the localhost, but this problem show up more often on jenkins (we use version 2.7.1). It is very strange to me that in most cases it is okay. However days ago one of my colleague had a branch and we tried several build on jenkins and it all failed due to this error. We had to change the pom file to remove wait on log, and use a fixed wait time to let build job pass. Unfortunately the logs on jenkins are gone as we only keep several recent builds. If I encounter this issue again (maybe later we put this option back again see if it happens) then I will give you more info here. |
Hmm... it randomly happened on our build job server again, here are part of the logs showing from the CI build job:
|
Ok, is you setup then, that you only start the DB container and run the tests from within Maven directly against the DB ? It also looks like that the containers are started in parallel to running your tests, so that sort of race seems to happen quite likely. (If it would be serial, I would expect some other line markers in the log between starting the test and starting the container). Could you past the whole Maven run to gist.github.com ? Without the btw, d-m-p stands for docker-maven-plugin (so, this plugin ;-) |
Okay I think I found the problem. When I turn off the wait on logs, the db has log like this:
Which is showing that there are two logs like BTW, is there any way to wait for a second log showing up? |
And this is the maven setup:
|
no, unfortunately its not that sophisticated ;-) Maybe you could try to wait for |
yeah, I will try that, thanks for the help :) |
Thinking about a race condition was the first impression I had, too… Doesn't happen usually if you use the failsafe plugin and run integration tests with Spring Boot (they take at my machines long enough to boot), but during unit tests… |
This is related to fabric8io#628 and fabric8io#608 and should fix both issues. Also, some refactoring has been performed for the wait checkers which were extracted into an extra package.
I just added multi line matching so that you can wait now (forthcoming release 0.20.1) with
so that the checks wait until of the second connection string appears. |
Works fine for me. Thank you very much! |
This is related to fabric8io#628 and fabric8io#608 and should fix both issues. Also, some refactoring has been performed for the wait checkers which were extracted into an extra package.
Description
We have this problem for some time with several recent version of our plug-in, which is that:
If my maven job is to use this plug-in to spin up a postgres docker container then run some dao tests against the postgres database. And the plug-in is set as wait on log such as:
Then occasionally, maybe 30% to 50% of the time (sometimes more frequent), that those dao tests cannot be carried out because when spring boots up the datasource immediately after the database container showing log
database system is ready to accept connections
, the datasource cannot connect onto database (it seems still need some micro delay to be ready).We have errors then such as:
Caused by: com.zaxxer.hikari.pool.HikariPool$PoolInitializationException: Failed to initialize pool: FATAL: the database system is starting up
Solution?
It would be nice to be able to add some option to set the delay after some log has appear.
Other info ...
mvn -v
) :Docker version 1.11.2, build b9f10c9
The text was updated successfully, but these errors were encountered: