Description Andrew Eidsness 2011-04-01 20:13:51 EDT

Build Identifier: M20100909-0800


I've found that my Profiles view (from the p2.ui.admin plugin) is not always
updated when it should be.  After some investigation, I think that the problem
is a race condition related to ignoring events in ProvUIProvisioningListener in
the p2.ui plugin.

It seems that while a bulk operation is in progress, the listener does not
broadcast any events.  There is code that takes care to broadcast repository
events, if the event is deemed to have come from the UI.  However, there is
no provision for broadcasting profile events.

My test scenario is as follows.  I have a test feature that consists of a
single plugin which is installed from a server on my LAN.  This feature
installs fairly quickly.  I've turned on tracing for
org.eclipse.equinox.p2.core/events/client.

1) Start Eclipse 3.6.1 with the p2.ui.admin plugin installed
2) Open the Profiles view
3) Open 'Help - Install New Software...'
4) Select my local update site from the 'Work with' combo box

At this point the trace shows that batch request has started.  The request seems
to be looking at all update sites in my list, I'm guessing that it is background
loading the cache in my session.

5) Select the update site for my feature
6) Follow prompts to install the feature

Following the trace, I can see that my feature is installed before large batch
job has completed.  Since the batch operation is still in progress, the event
that would update the Profiles view is ignored:

org.eclipse.equinox.internal.p2.ui.admin.ProfilesView Ignoring: ProfileEvent[PlatformProfile-->CHANGED]

Then I tried uninstalling my feature, restarting eclipse, and repeating the
process.  However, this time after doing step 4, I waited for tracing to show
that the batch operation was complete.

Then I proceeded with steps 5 and 6 as before.  In this sequence, the event is
processed:

ProfileEvent[PlatformProfile-->CHANGED]  --  <org.eclipse.equinox.internal.p2.ui.admin.ProfilesView>

And the view is updated as expected.

----

I've tried a few different fixes in ProvUIProvisioningListener.notify.  The
first was to change the code around line 76 (of file version 1.7) so that it
handled Profile events (in addition to the repository events that it handles
now).  However, I found that innerEvent was null in the case that reproduces
this problem.

The change that I found to work was to assume that the goal was to block only
Repository events.  The attached patch moves the check for Profile events higher
so that it is processed before the check that causes the event to be ignored.

I think that the real fix is to address this at a higher level.  The current
implementation seems to have a single manager processing multiple concurrent
operations.  The decision on ignoring events is shared between the operations,
so that only the last operation to complete gets to broadcast the updated
status.

I'm attaching the patch to better describe the hack that I found, even though
I don't think it is the right fix.

Reproducible: Always

Steps to Reproduce:
SESSION A:
0) Enable trace for org.eclipse.equinox.p2.core/events/client
1) Start Eclipse 3.6.1 with the p2.ui.admin plugin installed
2) Open the Profiles view
3) Open 'Help - Install New Software...'
4) Select an update site on your local network that has a small feature.
5) Install the feature

Observe that:
a) the install completes before the large batch update
b) the profiles view does not show the new feature
c) the trace statements show the ProfileCHANGED event being ignored

Exit Eclipse.

SESSION B:
0) Enable trace for org.eclipse.equinox.p2.core/events/client
1) Start Eclipse 3.6.1 with the p2.ui.admin plugin installed
2) Open the Profiles view
3) Open 'Help - Install New Software...'
4) Select an update site on your local network that has a small feature.
5) Wait for trace to show that the batch update operation has completed (about 2 minutes for me)
6) Install the feature

Observe that:
a) the profiles view immediately shows the new feature
c) the trace statements show the ProfileCHANGED event was processed