[DEAD-7] Deadlink module causes weird vaadin effects Created: 21/Mar/14  Updated: 05/Jul/14

Status: Open
Project: Deadlink
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Richard Unger Assignee: Marvin Kerkhoff
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLUI-1901 Asynchron Actions Closed
dependency
depends upon MGNLUI-2783 User is blocked in his browser sessio... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

I don't really know how to describe this, so I made a video:

http://ge.tt/4lG2iMS1/v/0

You can see me start a deadlink scan (of www.lfrz.at) and then observe the following:

second 12 - I switch away from deadlink and try to open the assets app while the scan is running. Note how the app opens, and then everything locks up. I can't get back to admin-central.

second 35 - I started the scan again, and now I switch around, I can switch to the assets app (which is already open), but when I start the pages app things become locked again.

second 70 - I started the scan a third time, and switch around between the apps. Note the very cool effect that happens after about second 75 - the UI begins to switch between the pages and deadlinks apps all by itself, back and forth. The animation effects when swirching apps make it look kind of smooth and cool, but I don't think it's desired behaviour

It's not browser-specific. I recorded this video on firefox, but I got the same thing to happen in chrome...

At a guess: maybe you're calling something UI-related from the worker threads? (not allowed, Vaadin is not useable by multiple threads concurrently!)

Or maybe the problem is more that the original command runs for too long...
The threading is realized in a pretty weird way:
the ScanCommand loops over the pages to scan - but this happens within the UI thread. Each page to be scanned is loaded and then the Links are scanned. Then the links are all checked, and only the link-checking happens in the worker-threads.
IMHO this is not the right approach. The entire scan, ie already the loop in the ScanCommand should be handled by the worker threads. The ScanCommand should return control to the UI thread immediately.



 Comments   
Comment by Richard Unger [ 21/Mar/14 ]

I you want me to I can look at refactoring this. Shouldn't be too hard, but I guess it will take a couple of hours. If you're planning to do this anyway (or have already started) I'll wait...

Comment by Marvin Kerkhoff [ 24/Mar/14 ]

This bug relates to MGNLUI-1901. Jan Haderka told me that i need to add the action in a command. But this doesn't work. You will have the same Problem if you want to publish a big structure e.x. inside the Asset app. Long runnings jobs are note threaded. A good workaround for this is to use a scheduleed job for this.

Comment by Richard Unger [ 17/Apr/14 ]

looks like magnolia has fixed the problem with long running actions...

will you change the code to use the new action classes that make use of the scheduler module?

Comment by Marvin Kerkhoff [ 05/Jul/14 ]

Hi Richard,

i will fix the issue in Version 1.2 which works then also with Magnolia 5.3

Thanks for reporting.

Generated at Mon Feb 12 00:42:55 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.