Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 333267 - [Workbench] UILockListener overwritten in LockManager#setLockListener
Summary: [Workbench] UILockListener overwritten in LockManager#setLockListener
Status: NEW
Alias: None
Product: RAP
Classification: RT
Component: Workbench (show other bugs)
Version: 1.4   Edit
Hardware: PC Linux
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-28 11:09 EST by Ralf Sternberg CLA
Modified: 2016-08-30 03:57 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Sternberg CLA 2010-12-28 11:09:50 EST 
Since the org.eclipse.core.internal.jobs.LockManager can only keep one single lock listener, different sessions in RAP overwrite each other's listeners. As a result, only the one Workbench instance that has been started latest, will receive aboutToWait() and aboutToRelease() notifications from the JobManager. See Workbench#runUI, line 2545.
Comment 1 Wolfgang Pedot CLA 2016-08-29 11:38:52 EDT 
This also keeps the Display instance from being GCed until the locklistener is overwritten by a new one.

Is using "allowDeadLock" a feasible workaround for this? The name of that parameter sure is scary...
Comment 2 Ivan Furnadjiev CLA 2016-08-30 03:17:44 EDT 
(In reply to Wolfgang Pedot from comment #1)
> This also keeps the Display instance from being GCed until the locklistener
> is overwritten by a new one.
> 
> Is using "allowDeadLock" a feasible workaround for this? The name of that
> parameter sure is scary...

Could you provide a fix through Gerrit [1]?

[1] https://eclipse.org/rap/source/ 
[2] https://wiki.eclipse.org/RAP/Git
Comment 3 Wolfgang Pedot CLA 2016-08-30 03:57:00 EDT 
Maybe I was not perfectly clear: "allowDeadLock" is a commandline-parameter for the framework so there is no code-change. If it is set the code-block that calls setLockListener is skipped (Workbench.runUI) but I dont know enough internals to decide if its a good idea to set that parameter.