-
Notifications
You must be signed in to change notification settings - Fork 5
Description
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
| public static void updateEngineInstances(ArrayList<Engine> updatedEngines) { | |
| BackendHelper.engines = FXCollections.observableList(updatedEngines); | |
| for (Runnable runnable : BackendHelper.enginesUpdatedListeners) { | |
| runnable.run(); | |
| } | |
| } |
Ecdar-GUI/src/main/java/ecdar/controllers/EngineOptionsDialogController.java
Lines 73 to 76 in a25b099
| // 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 theEngineOptionsDialogController.
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.