Bug 336240

Comment 1 Henrik Lindberg 2011-02-03 14:20:23 EST

I worked on the reporting of progress on the actual downloading (i.e. which URL, size and effective download speed), and it was a bit disappointing that the result of all downloads are merged into a single progress bar - using a different view with multiple bars, and making sure each thread reports on the correct monitor would be a big improvement IMO.

The entire "progress reporting" for p2 needs an overhaul.

Comment 2 Helmut J. Haigermoser 2011-02-04 06:07:29 EST

(In reply to comment #1)
> I worked on the reporting of progress on the actual downloading (i.e. which
> URL, size and effective download speed), and it was a bit disappointing that
> the result of all downloads are merged into a single progress bar - using a
> different view with multiple bars, and making sure each thread reports on the
> correct monitor would be a big improvement IMO.
> 
> The entire "progress reporting" for p2 needs an overhaul.

Yeah, reporting 3 downloads in one progress bar (but not merging the download speed) is confusing at best.

My proposed change would allow listeners to better display the progress in their own fashion, I for one use all info from the bus to show a message like this:

Downloading 3 artifacts at 200k/s total, 10000 of 200000 bytes received so far.


However, the event bus notifications could also be used to have three progress bars in parallel, with messages like this:
Downloading artifact at 200k/s from eclipse.org, 10000 of 200000 bytes received so far.
Downloading artifact at 10k/s from mirror.org, 9000 of 80000 bytes received so far.
Downloading artifact at 0k/s from notresponding.org, 0 of 200000 bytes received so far.


As you can see I'm not planning on showing the artifact name or the full URL, but that would be a choice I made, all the info would be available to the listeners....

Comment 3 Henrik Lindberg 2011-02-07 10:29:00 EST

One thing that is lacking in the p2 download is the ability to shift to another mirror when download speed is under a particular treshold - as long as there are no timeouts the download will continue. Having a more details progress-bar could allow functionality to cancel a particular (slow) download to let the overall process pick a better location - as a starting point for this "manual QoS optimizer" :) there would need to be a more detailed progress monitor.

Comment 4 Helmut J. Haigermoser 2011-02-18 09:35:41 EST

Created attachment 189275 [details]
first patch, meant for discussing our options only

Hi @ll :)
Using our installer I tried to come up with a few notifications sufficient for us to display a nice progress during the install. This patch here does just that, it sends enough notifications for us to consume, the following is now possible:
- show overall download rate
- show total bytes download 
- show bytes still to be downloaded
- show server
- show amount of parallel downloads


This patch is not a clean solution but a first step to start discussing what we can do, here is what I came up with in it:
- The DownloadManager sends two notifications: 
-- Download is starting for <repo>
-- Download is ending for <repo>
This change make sure listener on the event bus get a repo-independent notification. Most of the real mirroring is handled deep inside the repos, mirrorrequests and eventually inside the FileReader, architecturally I think having the download manager send out notification is the best way...

- The "BeginOperationEvent" publishes a read-only array of Operands now, for listeners to 
- check out how many IUs were being installed
- check out how many artifacts were installed
- find the overall size of the operation 


- The FileReader publishes the "ProgressStatistics" to the event bus each time it gets notified. This way clients can directly look at the statistics and pick information they need. I found this to work well, but it's architecturally problematic. FileReader will get notified even in the install phase, so clients need to know when to use the notifications and when not to (@see the above downloadmanager notifications on how to do that). Also, the progress statistics and the whole FileReader with it don' thave a relation to the artifact descriptor being downloading, all it knows about is a URI, a connection there would definitely help.

Let me know what you think, I'm willing to try completely different approaches for this and craft a patch to show, as said, this first patch is just meant to get a discussion going..

HTH,
Ciao, Helmoot

Comment 5 Helmut J. Haigermoser 2011-02-25 07:51:55 EST

(In reply to comment #4)
Guys, any news on this one, did you have a chance to look at my changes, did you see what I intended to do?
TIA,
Ciao, hh

Comment 6 Eclipse Genie 2019-09-10 07:11:05 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.