Bug 344989

Comment 1 Ralf Sternberg 2011-05-06 11:38:39 EDT

Created attachment 194949 [details]
Draft patch

This patch contains a refactoring that can be used as starting point for the re-design.

Comment 2 Rüdiger Herrmann 2011-05-18 07:59:58 EDT

Applied patch to CVS HEAD to prevent that it goes out of sync.

Comment 3 Rüdiger Herrmann 2011-07-11 11:56:28 EDT

Changed UICallBack to only activate UICallback in lifecycle responses, UICallback responses only trigger regular lifecycle requests, which in turn re-activate the UICallback if needed.
Changes are in CVS HEAD.

Comment 4 Rüdiger Herrmann 2011-07-13 09:37:40 EDT

Introduced sanity check for pending callback requests. In a predefined interval, it is checked whether the connection is still alive. If this is not the case, the waiting request is released.

Comment 5 Rüdiger Herrmann 2011-07-13 12:25:42 EDT

Changed UICallBackManager#blockCallBackRequest() and UICallBackServiceHandler#service() to answer duplicate callback requests with HTTP 409

Comment 6 Rüdiger Herrmann 2011-07-13 13:58:13 EDT

Created attachment 199609 [details]
Draft patch

Handles duplicate callback requests in that any pending previous request(s) is/are given the chance to terminate (calls releaseBlockedRequesst). Such terminated requests send an empty response.
The most recent incoming request becomes the currently active request. This information is held in a weak reference.

Comment 7 Chris Fairhall 2011-07-18 19:26:28 EDT

I've experienced a problem with a nightly build (see bug 351127 - rap-runtime-1.5.0-N-20110716-2110).

When the ProgressMonitorDialog's ModalContext tries to wake up the display with Display.wake, the method in which display.wake causes the wake up is to call Display.asyncExec(null) which has always worked (in 1.4.0 anyway). This nolonger wakes up the display so the ModalContext gets stuck on display.sleep();

Subclassing Display and overriding asyncExec to run an empty runnable instead of the special handling it does when passed a null fixes the problem but the root causes is still somewhere in the UICallback mechanism. 

Both display.asyncExec(Runnable) and asyncExec(null) end up calling UICallBackManager.releaseBlockedRequest but asyncExec(Runnable) also calls setHasRunnables(true) when the first runnable is added to the list.

Comment 8 Ralf Sternberg 2011-07-19 05:19:41 EDT

(In reply to comment #7)
This issue should be fixed in CVS HEAD / tomorrow's nightly build. Could you please check again and open a separate bug if the problem persists?

Comment 9 Ralf Sternberg 2011-07-19 10:23:55 EDT

The UICallback system has been redesigned.
The most notable change is that ui requests and callback requests do not overlap anymore. This decouples both requests and makes the overall system clearer and more robust.
We created a wiki page to explain it's ideas and concepts: http://wiki.eclipse.org/RAP/UI_Callback