Skip to content
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

DiagramServices::getEditPart(DDiagramElement) can cause deadlock #2894

Open
mPorhel opened this issue Sep 9, 2024 · 1 comment
Open

DiagramServices::getEditPart(DDiagramElement) can cause deadlock #2894

mPorhel opened this issue Sep 9, 2024 · 1 comment

Comments

@mPorhel
Copy link
Contributor

mPorhel commented Sep 9, 2024

In some situations, deadlock can occur during refresh of diagrams having the capability to display functional chains or physical paths: ie diagrams with Sirius post refresh extensions :

  • org.polarsys.capella.core.sirius.analysis.refresh.extension.ComponentArchitectureBlankRefreshExtension.postRefresh(DDiagram)
  • org.polarsys.capella.core.sirius.analysis.refresh.extension.DataFlowBlankRefreshExtension.postRefresh(DDiagram)
  • org.polarsys.capella.core.sirius.analysis.refresh.extension.EntityArchitectureBlankRefreshExtension.postRefresh(DDiagram)

The detected performance issue or potential deadlock comes from the DiagramServices::getEditPart(DDiagramElement) which uses an helper using Display.syncExec method to get the ActiveEditor.
This also means that a refresh occuring on a non active editor will not refresh the edit parts.

Reproduction scenario exists with Team for Capella:

  • when a user has received remote changes on a locked diagram, if the automatic refresh is disabled, this diagram will be frozen and will need a manual refresh to display the received remote changes and be refresh accordingly to potential local changes.
  • with Capella 6.1 and 7.0 (an dI assume 5.2/6.0), with the [LAB] [Build] All Components, Functions, CEs, FEs diagram from the IFE sample, I get a ~29s manual refresh for this particular scenario compared to an immediate (200ms to 1s regarding the versions) time for other refresh use cases of the same diagram
  • analysis targets the DiagramService::getEditPart implementation
mPorhel added a commit to mPorhel/capella that referenced this issue Sep 9, 2024
Change-Id: I653a0e579d58abf71f44ceb8eb85179cc07d5eb5
Signed-off-by: Maxime Porhel <[email protected]>
@mPorhel
Copy link
Contributor Author

mPorhel commented Sep 9, 2024

With the provided PR, the issue is no more reproduced with the scenario we have with Team for Capella.
The particular refresh done on a frozen diagram comes back to the same timings than other refreshes.

mPorhel added a commit to mPorhel/capella that referenced this issue Sep 25, 2024
Change-Id: I653a0e579d58abf71f44ceb8eb85179cc07d5eb5
Signed-off-by: Maxime Porhel <[email protected]>
GlennPlou added a commit to GlennPlou/capella that referenced this issue Oct 15, 2024
Signed-off-by: Maxime Porhel <[email protected]>
Signed-off-by: Glenn Plouhinec <[email protected]>
lredor pushed a commit that referenced this issue Oct 24, 2024
Signed-off-by: Maxime Porhel <[email protected]>
Signed-off-by: Glenn Plouhinec <[email protected]>
GlennPlou added a commit to GlennPlou/capella that referenced this issue Nov 20, 2024
Signed-off-by: Maxime Porhel <[email protected]>
Signed-off-by: Glenn Plouhinec <[email protected]>
tguiu pushed a commit that referenced this issue Nov 20, 2024
Signed-off-by: Maxime Porhel <[email protected]>
Signed-off-by: Glenn Plouhinec <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant