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
Dev Tools restart failures caused by a too short quiet period are hard to diagnose #31579
Comments
We're not aware of any problems in this area. Can you please provide a minimal sample and steps to reproduce the problem? |
Yeah sure, just created a sample web service using the same dependencies now with a single endpoint: It includes a Dockerfile from which the image can be built so you will need to have docker running in the background. Steps to reproduce:
At this point the docker container logs for the running service should throw the following exception which I have managed to replicate on this simplified example:
Hopefully that will help 👍 |
Thanks for the sample, @iranicus. I've tried to reproduce the problem and have thus far been unable to do so. I used Eclipse to make the change to the application code. This resulted in the following logging:
On the remote side, this triggered the expected restart which was successful:
I have removed Lombok from the app as I don't have that Lombok plugin installed in Eclipse. I wouldn't expect that to make a difference though. I'll try with IntelliJ next. |
The restart was also successful using IntelliJ and with Lombok reinstated:
I've also tried making changes to I notice that the original error reported above is |
I will take another quick look this afternoon and see if I can replicate the problem again using the sample chat application then get back to you. |
Yeah the names of the classes were changed for anonymity before the attached chat application was created for demo purposes. I have repeated the steps I mentioned before and have managed to run into the same problem when I changed the value of the VERIFY_MSG field in the VerificationService and rebuilt the service while it was running:
The mentioned failure at the end of the logs was due to the service stopping, the docker container logs showing the following:
The service started up fine at 11:51, then mentioned changes were made whilst IntellIJ had the Remote Debug running on port 8120 and I triggered a manual build in the IDE. This sure enough caused the service to restart which you can see from 11:52 which lead to the eventual exception shown a couple of seconds later when the updated VerificationService dependency was being loaded for OtherService. Could you try making the same changes to the VerificationService then do a rebuild? |
Unfortunately, this is exactly what I tried already. I changed the value of the Your logs above show Java 11.0.15 being used:
Whereas my logs show Java 11.0.16:
Given that the JVM is determined by the container, it's not immediately obvious to me why they're different. Perhaps this is (part of) the problem? It could also be the IDE. It works for me with IntelliJ IDEA 2021.2.2 Ultimate Edition. What version are you using? |
Could be, so I am using IntelliJ IDEA 2022.1.4 (Ultimate Edition) having recently updated but have re-tried and have got the same result. |
I've upgraded to IntellIJ IDEA 2022.1.4 and I can now reproduce the problem. When I trigger a rebuild after changing the value of
At the time of this failure, the remote application logs the following:
Now to see if I can figure out why it only fails with a particular version of IntelliJ IDEA. |
The way that updates to class files are made appears to have changed in more recent versions of IntellIJ IDEA. When I change The problem can be avoided by tuning the quiet period that's required before a restart. The following works for me: spring:
devtools:
remote:
secret: mysecret
restart:
quiet-period: 800ms There's a usability issue here as this wasn't easy to figure out. Perhaps we should log more about the change? Rather than just logging the number of class resources that have changed in some way, a break down by the kind of change would have helped. I also wonder if the behavior when the restart triggered by the upload fails could be improved. At the moment, the restart failure causes the application to exit. |
Hmm, I did try messing around with setting the quiet-period before when following the documentation Spring Boot Docs - Configuring File System Watcher In regards to the logging out of updated classes I do think it would be beneficial to have the breakdown for clarity. I was surprised the application exited since this would become a problem if the appropriate quiet-period isn't set to avoid this (chances are it will be different per machine unless a high value is set to try cover all cases). The service would therefore manually need to be restarted. |
Thanks for trying tuning of the quiet period. It's good to hear that increasing it resolves the problem for you too.
You may want to configure the quiet period in a global settings file that's appropriate for your local development environment (IDE, etc.). |
The team discussed this issue and we think we should add more log information - initially a single line stating how many adds/deletes/changes were pushed to the server. In this case, this would have been a nice clue about that class being deleted+added. We can always consider more detailed log messages in the future. We also discussed changing the default value for the restart |
I've added some info-level logging that provides an overview of the changes that are going to be uploaded. When the quiet period is too short and a modification appears as a delete followed by an add, those messages look like this:
The second upload fails as the first triggered a restart which failed due to the missing class. As a result, we then see the existing warn-level logging:
I've also made a similar change to local dev tools which now logs messages like this when a restart is triggered:
|
Spring Boot Dev Tools 2.6.6
Spring Boot 2.6.6
Maven
Java 11
Could be related to #1106
I have an issue when trying to make changes against the application running inside a docker container, when I trigger a build in the IDE the running service throws the following:
It appears to be a Class Loading issue, we use lombok annotations for our class dependency injections which might be the cause of this. I have tried replacing it in the VerificationService class with a constructor and it still throws the same issue.
Followed the instructions found on the spring boot dev tools docs - classloading issues with disabling the restart and this stopped the error but then changes made weren't applied after the LiveReload.
Instructions were followed for spring boot dev tools docs - remote application which I run before making any changes in the IDE.
The container isn't currently assigned to any network and has exposed port 8120
At the moment my workaround this issue is to instead not use the dev tools (removing it entirely) but use the native Remote JVM Debug of IntelliJ and connect to port 5005. I have been able to make changes which are reflected in the running service this way (though limited to no schema or method signature changes) but it would be nicer if this was working with dev tools.
Thanks now.
The text was updated successfully, but these errors were encountered: