You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
⚠️ 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.
The text was updated successfully, but these errors were encountered:
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 anEngine
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.The text was updated successfully, but these errors were encountered: