Eclipse Community Forums: Equinox » Stuck progress bar while installing p2 artifacts

Help

Home

Home » Eclipse Projects » Equinox » Stuck progress bar while installing p2 artifacts

Show: Today's Messages :: Show Polls :: Message Navigator

Stuck progress bar while installing p2 artifacts [message #1818622]

Fri, 20 December 2019 17:24

Aleksei Airapetov

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?

Report message to a moderator

Re: Stuck progress bar while installing p2 artifacts [message #1818823 is a reply to message #1818622]

Mon, 30 December 2019 06:18

Ed Merks

Messages: 33226
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/

Report message to a moderator

Previous Topic:	Http Whiteboard propertytypes annotation support
Next Topic:	Issue with OSGi Config Admin, DS and component factory

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sun Oct 13 07:47:48 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter