When the user saves changes to the engines through the EngineOptionsDialog, all engines are re-instantiated and their connections are closed. It would be more efficient to only close the connections that are no longer in the active port range of the affected engines.
|
public static void updateEngineInstances(ArrayList<Engine> updatedEngines) { |
|
BackendHelper.engines = FXCollections.observableList(updatedEngines); |
|
for (Runnable runnable : BackendHelper.enginesUpdatedListeners) { |
|
runnable.run(); |
|
} |
|
} |
|
// Close all engine connections to avoid dangling engine connections when port range is changed |
|
try { |
|
Ecdar.getBackendDriver().closeAllEngineConnections(); |
|
} catch (IOException e) { |
⚠️ This change might seem fairly easy, but it should include a refactor of the way engines are referenced and handled in the EngineOptionsDialogController.
This also becomes an issue if long-running queries are started and then the port range is changed for the associated engine in order to run other queries. This case would result in the long-running query being canceled. (Thanks to @Brandhoej for this example of the issue)
Suggested approach
I suggest that the EngineInstance (the visual representation of the engine within the EngineOptionsDialog) does not operate on the engines, but instead takes an Engine as a constructor parameter for populating the input fields and then has a method for constructing an engine based on the values of these fields.
When the user saves changes to the engines through the
EngineOptionsDialog, all engines are re-instantiated and their connections are closed. It would be more efficient to only close the connections that are no longer in the active port range of the affected engines.Ecdar-GUI/src/main/java/ecdar/backend/BackendHelper.java
Lines 121 to 126 in a25b099
Ecdar-GUI/src/main/java/ecdar/controllers/EngineOptionsDialogController.java
Lines 73 to 76 in a25b099
This also becomes an issue if long-running queries are started and then the port range is changed for the associated engine in order to run other queries. This case would result in the long-running query being canceled. (Thanks to @Brandhoej for this example of the issue)
Suggested approach
I suggest that the
EngineInstance(the visual representation of the engine within theEngineOptionsDialog) does not operate on the engines, but instead takes anEngineas a constructor parameter for populating the input fields and then has a method for constructing an engine based on the values of these fields.