Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » Stuck progress bar while installing p2 artifacts
Stuck progress bar while installing p2 artifacts [message #1818622] Fri, 20 December 2019 17:24 Go to next message
Aleksei Airapetov is currently offline Aleksei AirapetovFriend
Messages: 13
Registered: December 2019
Junior Member
Hello

I am currently working on a project that uses the Oomph and I have encountered such behavior that when installing the product the progress bar stops at about 70% while downloading artifacts. At first glance you might think that there was an application error, although the logs say that the artifacts are being normally downloaded.

The same behavior can be observed in Eclipse installer - in the advance mode you can see frequent entries in the logs like "Downloading <something>" or "Fetching <something>" while the progress bar just stands in place.

So I decided to investigate and debug this issue and I discovered two places in the code where the SubMonitor#convert method is used:
https://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse.equinox.p2.artifact.repository/src/org/eclipse/equinox/internal/p2/artifact/repository/simple/SimpleArtifactRepository.java#n835
and
https://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse.equinox.p2.artifact.repository/src/org/eclipse/equinox/internal/p2/artifact/repository/simple/DownloadJob.java#n61

I suppose the problem is that the child monitor is supposed to be created however the method returns the same object (inside the method there is the comment that says Quote:
Optimization: if the given monitor already a SubMonitor, no conversion is necessary
) so the subsequent call to the subMonitor#done method actually terminates the parent monitor. I believe this is the reason that the installation progress looks ragged.

I tried to fix the corresponding section of the method DownloadJob#run starting from line 61 (using this manual https://wiki.eclipse.org/Progress_Reporting) to make it look like this:
SubMonitor subMonitor = SubMonitor.convert(masterMonitor, requestsPending.size());
subMonitor.beginTask("", 1); //$NON-NLS-1$
subMonitor.setWorkRemaining(requestsPending.size());
IStatus status = repository.getArtifact(request, subMonitor.newChild(1));
if (!status.isOK()) {
	synchronized (overallStatus) {
		overallStatus.add(status);
	}
}

and just commented this line in SimpleArtifactRepository:
https://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse.equinox.p2.artifact.repository/src/org/eclipse/equinox/internal/p2/artifact/repository/simple/SimpleArtifactRepository.java#n845

The corrected code seems to work properly from the UI perspective (tested it in Eclipse installer) so my question is is this the correct solution and whether there are any side effects in such changes that I may not know about?
Re: Stuck progress bar while installing p2 artifacts [message #1818823 is a reply to message #1818622] Mon, 30 December 2019 06:18 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 32494
Registered: July 2009
Senior Member
It looks to me like the SubMonitor API is not being used properly in these places (and not just these places). Also even your code doesn't look right to me though it's based on the wiki which also doesn't look quite right to me either. The Javadoc for SubMonitor says things like "It is not necessary to call beginTask() or done() on an instance of SubMonitor", "Use SubMonitor.split(...) whenever you need to call another method that accepts an IProgressMonitor.", and even "It is never necessary to call done() on a monitor obtained from convert or progress.split(). The JavaDoc contract makes this the responsibility of the caller." But in these places we see it uses newChild, not split, and there are calls to done; calls to done should be done by the thing that created the progress monitor, so not in a method that is passed a progress monitor argument. It all just looks very wrong to me. :-(

So one needs to question, where in the overall call stack is this all going horribly wrong and when will a change/fix in a method that looks wrong break some bad assumption in a caller that itself is also wrong? This will not be easy to fix and it will not be easy to test whether any changes fix one use case without breaking another. ..


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:Http Whiteboard propertytypes annotation support
Next Topic:Issue with OSGi Config Admin, DS and component factory
Goto Forum:
  


Current Time: Wed Sep 28 10:03:05 GMT 2022

Powered by FUDForum. Page generated in 0.01463 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top