-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Reload of dev-services broken #20197
Labels
area/devservices
kind/bug
Something isn't working
triage/duplicate
This issue or pull request already exists
Comments
/cc @stuartwdouglas |
Yes, looks like it. |
I will investigate the problem with the setting of the image name causing a reload a bit further and possibly report an issue for that. |
For the other issue I filed #20214. |
Thanks @knutwannheden, I'll be marking this as duplicate and close it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/devservices
kind/bug
Something isn't working
triage/duplicate
This issue or pull request already exists
Describe the bug
When the Quarkus application is restarted in the dev-mode and a dev-service also needs to be restarted, the application can after the restart no longer access the newly started dev-service.
I debugged this in the case of a PostgreSQL database, where I explicitly set the property
quarkus.datasource.devservices.image-name
inapplication.properties
to cause the dev-service to be force-restarted (which in itself may be a separate bug). The Docker container is properly restarted (listening on a new port) and the new configuration is correctly exposed usingRunTimeConfigurationDefaultBuildItem
instances. But when the application is restarted and ends up inio.quarkus.deployment.steps.ConfigGenerationBuildStep#generateConfigClass()
the method immediately returns asliveReloadBuildItem.isLiveReload()
evaluates totrue
. Consequently theRunTimeConfigurationDefaultBuildItem
instances have no effect and the Quarkus application attempts to access the database using the old port rather than the new port.Expected behavior
The Quarkus application should after a restart in dev-mode be able to access any restarted dev-services.
Actual behavior
The dev-services get restarted and will typically be listening on new ports, but the restarted Quarkus application will try to access the dev-service on the ports it used before the restart, which then fails.
How to Reproduce?
quarkus.datasource.devservices.image-name=postgres:13
andquarkus.flyway.migrate-at-start=true
inapplication.properties
s
Output of
uname -a
orver
MSYS_NT-10.0-22000 WIN10-KNUT 3.1.7-340.x86_64 2020-10-23 13:08 UTC x86_64 Msys
Output of
java -version
openjdk version "11.0.9" 2020-10-20 LTS OpenJDK Runtime Environment Zulu11.43+22-SA (build 11.0.9+11-LTS) OpenJDK 64-Bit Server VM Zulu11.43+22-SA (build 11.0.9+11-LTS, mixed mode)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.2.2.Final
Build tool (ie. output of
mvnw --version
orgradlew --version
)Maven 3.8.1
Additional information
No response
The text was updated successfully, but these errors were encountered: