Community
Participate
Working Groups
I thought that the belongsTo call would get rid of all matching synchronizations. But it appears that with scheduled syncs, they stay in the view. Also, the timestamp isn't shown for when they terminated.
Another thing is that you can't get rid of them when the remove button is pressed.
I've checked our code and belongsTo is called by the progress view but for some reason matching jobs are not really removed. The call to belongsTo is returning true and the progress view looks like it is removing elements, but they are not actually removed from the UI. Also, the finished tasks in the progress view can never be removed by pressing the remove all, or the 'x' button. To reproduce: 1. create a cvs synchronization 2. from the sync view menu select Schedule... 3. schedule every minute 4. watch the jobs accumulate in the sync view
The problem is that the view is showing persisted groups, not jobs so when the code that checks for terminated jobs is running it does not clear it out - likewise the X does not work as it is a group. The right answer is likely to persist the group in the view rather than the job but I don't want to mess with this code so close to a milestone as I am not familiar with it.
*** Bug 63989 has been marked as a duplicate of this bug. ***
*** Bug 65026 has been marked as a duplicate of this bug. ***
*** Bug 61668 has been marked as a duplicate of this bug. ***
Whis is it that only the Bug Reporter gets CC'ed when a duplicate is resolved? Shouldn't everyone who was CCed get carried over?
Here is an easily reproducable case in RC3. 1) load ui, workbench,ide, jface and views 2) Select all 3) Synchronize with repository 4) Hit Run and Background 5) Synchronize again 6) About half of the time you will get a Finished job with no details that cannot be removed.
Note that for the case below closing and reopening the view cleared these out
Re #1: Currently removing a kept job is done by removing it from the model (FinishedJobs) and letting notification remove it from the view. In this PR the KEEPONE property results in a too early removal of the original job from the model. If later the UI is used to remove the job from the model, the model doesn't have the job (because it was already removed), and doesn't send out notification to the view. As consequence the job cannot be removed from the view. I suggest to change the code in NewProgressView.JobItem.kill() so that the dispose and the refresh is always done (without going through the model). This will ensure that finished jobs can always be removed even if the model in FinishedJobs does not know them. On the other hand, if the model knows them and sends out remove-notification, but the job already has been removed from the view, the remove event has no effect (see code in NewProgressViewer.remove(Object[])).
Created attachment 12639 [details] Patch for NewProgressViewer.java Patch enables to remove finished jobs without relying on model notification.
*** Bug 68049 has been marked as a duplicate of this bug. ***
There is still a case where this patch fails: 1) Load ui,views,workbench, jface and ide 2) Sync 3) Run in background 4) Do a couple of more synchs before the first one is done Dead groups still around
The patch does not fix the original problem, but should allow to remove jobs in any situation (see comment #1). I'm still working on the real problem, but the patch should go into RC4 in any case. Are you saying in comment #13 that you couldn't remove the stale jobs from the ProgressView?
Yes - the stale groups were still hanging around but I will retest with just this patch,
Tod, I'm bitten by the following problem with JobInfos: Whenever a Job that belongs to a group is rescheduled, the newly generated JobInfos have their parent initialized to null (instead of the original GroupInfo). As a consequence the new JobItem is no longer associated with the original group and it gets a new entry in the ProgressViewer. You can verify this by creating a rescheduled group with the KEEP flag set. The first time it appears in the ProgressView as a Group, and when rescheduled it appears as a TestJob. Can you please look into this problem? Without the correct groupinfo I have a hard time fixing this problem.
Stale groups are a consequence of the API -from setProgressGroup() * The progress group must be set before the job is scheduled. * The group will be used only for a single invocation of the job's * <tt>run</tt> method, after which any association of this job to the * group will be lost. So there will always be a risk of stale groups here.
Which means that I cannot really fix the real problem, but only cure the symptoms: make removal of stale stuff reliable. Right?
Correct. I think the best solution is to nver have a group in the FinishedJobs but only ever show a finished job. Group info is not useful after the jobs is done anyways.
Created attachment 12715 [details] a patch for org.eclipse.ui.internal.progress This patch fixes - a problem where the KEEPONE flag would actually remove all jobs of a family from the model because it would perform the belongsTo check even on itself. As a consequence it was hard to remove those items from the view, because it was waiting for remove-notification from the model, which would never come. - adds a reliable way to remove stale items from the ProgressView and the FinishedJobs model (press the Remove All Finished Tasks button). It does not tackle other issues because that would larger code changes and would be high risk. Tod, could you give it a try please? Thanks.
Released the patch with updated copyrights. Reviewed with JM and MVM. The problem with not clearing elements when you click the X persists but at least you can clear all. I think this is all we should do for 3.0 and revisit the rest of the issues in 3.0.1. We should enter a seperate problem report for the remaining issues and close this one.
I have entered the remaining issues in Bug 68434 which we can revisit post 3.0. Marking this as fixed as it is now possible to clear these values.
Verified in 20040623-1600
