Bug 305163 - [ui] ProvisioningJob still running late in shutdown process
Summary: [ui] ProvisioningJob still running late in shutdown process
Status: VERIFIED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: p2 (show other bugs)
Version: 3.6   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.6 M7   Edit
Assignee: Susan McCourt CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-09 09:55 EST by John Arthorne CLA
Modified: 2010-04-26 12:30 EDT (History)
0 users

See Also:


Attachments
Log file (6.85 KB, text/plain)
2010-03-09 09:56 EST, John Arthorne CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Arthorne CLA 2010-03-09 09:55:41 EST
I found several errors in my log today after upgrading, which shows a ProvisioningJob was still running very late in the shutdown process. For example one NPE is because the extension registry has already been shutdown. We should be canceling and joining these jobs, probably in the org.eclipse.equinox.p2.operations bundle activator's stop method.
Comment 1 John Arthorne CLA 2010-03-09 09:56:06 EST
Created attachment 161467 [details]
Log file
Comment 2 John Arthorne CLA 2010-03-09 09:59:54 EST
Actually I see from the log that this didn't happen after upgrading because the build ids are the same. I had just upgraded, but in this situation I was uninstalling a feature (MAT), which required a restart. Specifically I did this:

1) Opened install new software dialog
2) Clicked the "what is already installed link"
3) From that dialog, selected a feature and uninstalled it
4) On restart prompt, click ok to restart

So, I had the install new software dialog open in the background the whole time. I suspect that's where the ProvisioningJob in question comes from.
Comment 3 Susan McCourt CLA 2010-03-09 11:07:36 EST
thanks for the scenario, John.
Comment 4 Susan McCourt CLA 2010-04-19 13:42:58 EDT
Fixed in HEAD >20100419.
The jobs you observed that were still running were the "load metadata repository jobs."  The install wizard starts this job in the background when it opens.  This is the job that was still running after p2 shut down.  These jobs are started by the UI, so I added code in the ui bundle activator stop() method to cancel and then join on that job family.  

A risk here is that a non-responsive repository or long timeout could prevent the UI bundle from stopping (and therefore prevent the restart from occurring).  AFAIK, the "respond to cancel" work we did near the end of 3.5 should prevent this from happening, but we should be on the lookout for reports of slow/unresponsive restarting.
Comment 5 Susan McCourt CLA 2010-04-26 12:30:33 EDT
verified in 20100425-2000.
However there is a variant of this bug still around.
The deferred content tree fetch jobs can cause the same kind of problem.
Cloning this bug to track that case.