fix: correctly stopping gpsd thread #5585
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes a bug that happened when the PositionService provider was switched from
gpsd
to an other service (MM or Serial): after applying the new configuration in the PositionProvider tab and refreshing the WebUI, the latter get stuck. In general, each call to the PositionService for a certain time after the switch would be stopped due to this problem.This happened because when the stop method was called, the code would take all the time allowed in the
executor.awaitTermination(1, TimeUnit.MINUTES)
before killing the thread, resulting in blocking the web ui that asks to update its location information.The cause of the long await was that the Future<?> was not canceled before the calling to the
executor.shutdown()
, so the latter would fall in a bad state that required the thread kill.Now before the shutdown of the thread, the Future<?> is canceled and the web ui is not blocked.
Related Issue: This PR fixes/closes {issue number}
Description of the solution adopted: A more detailed description of the changes made to solve/close one or more issues. If the PR is simple and easy to understand this section can be skipped
Screenshots: If applicable, add screenshots to help explain your solution
Manual Tests: Optional description of the tests performed to check correct functioning of changes, useful for an efficient review
Any side note on the changes made: Description of any other change that has been made, which is not directly linked to the issue resolution [e.g. Code clean up/Sonar issue resolution]