Skip to content
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.

Sign up for GitHub

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

Jump to bottom

devmode breaks when updating pom.xml #40848

Closed
maxandersen opened this issue May 26, 2024 · 5 comments · Fixed by #41043
Closed

devmode breaks when updating pom.xml #40848

maxandersen opened this issue May 26, 2024 · 5 comments · Fixed by #41043
Labels
area/devmode kind/bug Something isn't working
Milestone
3.11.2

Comments

@maxandersen
Copy link
Member

Describe the bug

in past I could add a maven dependency and quakrus devmode would restart.

now when I do it devmode crashes.

ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c:700]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:57 min
[INFO] Finished at: 2024-05-26T23:38:51+02:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal io.quarkus.platform:quarkus-maven-plugin:3.10.2:dev (default-cli) on project jconqbot: Failed to run: Dev mode process did not complete successfully -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response
@maxandersen maxandersen added the kind/bug Something isn't working label May 26, 2024
@geoand
Copy link
Contributor

geoand commented Jun 6, 2024

I tried this a few times and could not reproduce the problem

@gsmet
Copy link
Member

gsmet commented Jun 6, 2024

So... I got hit by this one and I have a theory. Let's keep it open, I'm working on it :).

@gsmet
Copy link
Member

gsmet commented Jun 7, 2024

So to give a bit more details, I got hit by that when working on preparing the workshop. And the problem was when the default debug port was already used by another app.
We don't handle this case very well on restart.

PR to come.

gsmet added a commit to gsmet/quarkus that referenced this issue Jun 7, 2024
@gsmet
Make sure we transmit the actual debug port to next dev mode run
bd9b911 
When starting dev mode, the debug port might not be free and we might
use a random one.
When restarting dev mode (for instance when you adjust the pom.xml), we
should try to reuse this port instead of defaulting to the initially non
free one.

Also the port being free is tested when we build `DevModeRunner`, so we
need to make sure we stop the old runner before build()ing the new
instance (and not just before we start the new one).

Fixes quarkusio#40848
gsmet added a commit to gsmet/quarkus that referenced this issue Jun 7, 2024
@gsmet
Make sure we transmit the actual debug port to next dev mode run
6e1d71f 
When starting dev mode, the debug port might not be free and we might
use a random one.
When restarting dev mode (for instance when you adjust the pom.xml), we
should try to reuse this port instead of defaulting to the initially non
free one.

Also the port being free is tested when we build `DevModeRunner`, so we
need to make sure we stop the old runner before build()ing the new
instance (and not just before we start the new one).

Fixes quarkusio#40848
gsmet added a commit to gsmet/quarkus that referenced this issue Jun 7, 2024
@gsmet
Make sure we transmit the actual debug port to next dev mode run
2233494 
When starting dev mode, the debug port might not be free and we might
use a random one.
When restarting dev mode (for instance when you adjust the pom.xml), we
should try to reuse this port instead of defaulting to the initially non
free one.

Also the port being free is tested when we build `DevModeRunner`, so we
need to make sure we stop the old runner before build()ing the new
instance (and not just before we start the new one).

Fixes quarkusio#40848
@gsmet gsmet mentioned this issue Jun 7, 2024
Merged
@quarkus-bot quarkus-bot bot added this to the 3.12 - main milestone Jun 7, 2024
@maxandersen
Copy link
Member Author

thanks for spotting and fixing this @gsmet - was driving me mental and yes; good catch on it being caused by running multiple quarkus apps...which is what i normally do which is explains why @geoand couldn't reproduce it.

@geoand
Copy link
Contributor

geoand commented Jun 10, 2024

It all adds up :)

@gsmet gsmet modified the milestones: 3.12 - main, 3.11.2 Jun 10, 2024
gsmet added a commit to gsmet/quarkus that referenced this issue Jun 10, 2024
@gsmet
Make sure we transmit the actual debug port to next dev mode run
8140a9a 
When starting dev mode, the debug port might not be free and we might
use a random one.
When restarting dev mode (for instance when you adjust the pom.xml), we
should try to reuse this port instead of defaulting to the initially non
free one.

Also the port being free is tested when we build `DevModeRunner`, so we
need to make sure we stop the old runner before build()ing the new
instance (and not just before we start the new one).

Fixes quarkusio#40848

(cherry picked from commit 2233494)
holly-cummins pushed a commit to holly-cummins/quarkus that referenced this issue Jul 31, 2024
@gsmet @holly-cummins
Make sure we transmit the actual debug port to next dev mode run
ec73470 
When starting dev mode, the debug port might not be free and we might
use a random one.
When restarting dev mode (for instance when you adjust the pom.xml), we
should try to reuse this port instead of defaulting to the initially non
free one.

Also the port being free is tested when we build `DevModeRunner`, so we
need to make sure we stop the old runner before build()ing the new
instance (and not just before we start the new one).

Fixes quarkusio#40848
danielsoro pushed a commit to danielsoro/quarkus that referenced this issue Sep 20, 2024
@gsmet @danielsoro
Make sure we transmit the actual debug port to next dev mode run
76d4e4c 
When starting dev mode, the debug port might not be free and we might
use a random one.
When restarting dev mode (for instance when you adjust the pom.xml), we
should try to reuse this port instead of defaulting to the initially non
free one.

Also the port being free is tested when we build `DevModeRunner`, so we
need to make sure we stop the old runner before build()ing the new
instance (and not just before we start the new one).

Fixes quarkusio#40848
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/devmode kind/bug Something isn't working
Projects
None yet
Milestone
3.11.2
Development

Successfully merging a pull request may close this issue.

Make sure we transmit the actual debug port to next dev mode run gsmet/quarkus
3 participants
@maxandersen @gsmet @geoand