Community
Participate
Working Groups
Created attachment 98826 [details] the stack where it "hangs" I took 1 h to finish.
Created attachment 98827 [details] screenshhot
Susan, can you take a look at this stack dump? Two strange things that jumped out at me: - Does the UI need to use a synchronous listener on the event bus? This is causing another thread that is trying to publish an event to be blocked. - Why does the UI need to load the repository here? I would think the repository would be displayed as a collapsed node in the available software tab. Perhaps Michael was in the group by category or name mode. It's a mystery why there are repository ADD events happened here at all. They might be events from a previous install operation that are still running. Michael, had you just recently installed something new before doing the uninstall?
Be fore that, I added the feature I tried to uninstall (see bug 230379).
> - Does the UI need to use a synchronous listener on the event bus? This is >causing another thread that is trying to publish an event to be blocked. It is not necessary, it has probably always been this way. Since any UI work must be done in the UI thread anyway, most work is dispatched to a UI asynch anyway. I can change this. > - Why does the UI need to load the repository here? I would think the >repository would be displayed as a collapsed node in the available software >tab. This was a usability issue. Users wanted to be able to see the added content right away rather than searching for it in a collapsed tree, especially if it appeared in the "Other" category where they had no idea where to look. (For example bug 225326 comment 3. See also bug 216028 comment 18 and bug 216028 comment 24). >It's a mystery why there are repository ADD events happened here at all. They >might be events from a previous install operation that are still running. >Michael, had you just recently installed something new before doing the >uninstall? >Before that, I added the feature I tried to uninstall So it sounds to me like the add event is expected. I think the thing to do here is: 1) change the listener to be asynchronous 2) perform the load in a job and then do the expand/visible work when the job is done. I knew I was cheating when I did the load in the event handler..this is from the code // We rely on the fact that repository addition happens // in a job. We would get burned by this assumption if other // code adds repositories in the UI thread. // For now we assume that loading the repo while receiving // the add event won't block the UI. Do this // first before expanding.
Updated title to reflect the issue.
*** Bug 230379 has been marked as a duplicate of this bug. ***
Created attachment 98981 [details] patch with suggested changes >1) change the listener to be asynchronous done >2) perform the load in a job and then do the expand/visible work when the job >is done. the refresh of the view is immediate since the user wants to see the new URL show up in the list (or Pending... if not viewing by site). Then the load is done in a job, and when the job is done, the expansion is done if the user hasn't already tried to expand something, or if some other load job hasn't already been started. This ensures that the repo only gets expanded automatically iff - the repo is the most recent one added - the user hadn't already expanded or collapsed something manually
John, can you please review this patch? I've run with it for awhile today and it seems to be working well. Of course, I could not reproduce the deadlock consistently, but I can say I haven't seen it since the patch, and in general it seems a lot snappier adding repos now that the first refresh happens instantly. One change I plan to make that is not shown in the patch is externalizing the job name. I didn't do that because I have bunch of NLS catalog changes in my workspace associated with a different patch waiting for review. I'll externalize the string once the unrelated changes are released.
Created attachment 99110 [details] this one includes the NLS changes
+1, looks good. The main risk to me is the possibility of side-effects from switching to an asnchronous provisioning event listener. However, it looks like the listener and subclasses do all their work in an asyncExec anyway, so this should be ok.
Released to HEAD >20080507
