Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325151

Summary:

aggregator editor unusable while "loading repositories"

Product:

[Technology] CBI

Reporter:

David Williams <david_williams>

Component:

CBI p2 Repository Aggregator

Assignee:

Project Inbox <b3.aggregator-inbox>

Status:

RESOLVED NOT_ECLIPSE

QA Contact:

Severity:

major

Priority:

CC:

henrik.lindberg

Version:

unspecified

Target Milestone:

---

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
3 stack dumps, taken a minute apart to see what's being busy	none

Description David Williams

2010-09-13 14:12:35 EDT

I've found the b3 aggregator very nice ... except for one thing ...

Its almost impossible to "get work done" because it spends so much time, and takes so long, "loading repositories". If I let it run for several hours, it eventually stops ... guess it catches up ... but it seems with the least change or stopping and restarting workbench, causes it all to start over again, and takes _forever_ each time.

I'm hoping there's some setting I can change? That's not obvious. Such as, I turned off "automatically build project", and was hoping maybe that'd stop it, but didn't seem too effect it.

Also, once they get started, I find it basically impossible to cancel them. I can click on the red square on each of the 20-40 jobs that shat show up in progress dialog, and they say "cancel requested" but that doesn't seem to really stop anything (and, I'd hate to have to make 20-40 clicks just to get my workbench responsive again).

Obviously, there's times the editor needs completely up-to-date data ... but is there anyway this can be done more lazily ... and also put the user more in control?

As a concrete example, it's hard to check things in and out of cvs once all these jobs get going. Also, the 'decorators' in the UI are not updated in a timely fashion when all these jobs are running.

All in all, in other words, the editor is not very useful/usable due to this performance issue.

Is there anything in the model itself that can/should be changed?

I'm assuming you (b3 aggregator editor team) are aware of this problem, since surely you use helios and indigo sites yourselves ... if nothing else, to test your editor! ... but thought I should document my experience, in case either a) you are waiting to hear from community :) or b) I have something set or setup incorrectly.

Thanks,

Comment 1 Henrik Lindberg

2010-09-14 09:56:19 EDT

This is a known issue. The main problem is naturally that certain operations are very slow. When it takes hours to operate, I wonder if this could be caused by hitting slow mirrors. 

We still have to come up with an approach that makes it possible to work with the tool while things are loading slowly.

Comment 2 David Williams

2010-12-20 15:51:34 EST

I have just recently noticed a huge difference between windows and linux ... at least my particular installs and machines. As far as I know, the install should be equivalent, (and the windows hardware faster) but the the windows machine does "take hours" ... the linux machine just takes "several minutes". I've not done exact testing, but huge, huge difference. They are on same network. 

Any observations of what I might look at to account for this?

Comment 3 David Williams

2010-12-21 00:21:20 EST

Created attachment 185612 [details]
3 stack dumps, taken a minute apart to see what's being busy

I have sort of narrowed down what's "special" about my windows machine/install. It is related to the VPN I run to access my corporate networks. I need to emphasize the VPN is also running on the Linux machine ... but, it is a slight different version ... maybe older ... maybe not as many options for me to set incorrectly? Whatever the reason, if I just turn off the VPN on my windows machine, then "verify" starts to take 5 minutes like on Linux (with VPN), instead of the 60 or 90 minutes it takes on Windows with VPN. 

I've attached some thread dumps taken while the VPN was enabled and taking a long time ... maybe someone could tell from looking at them what the program was trying to do that it normally would not do so much of. The many calls to "getIEProxySettings" type functions is what got me looking at my whole network set up ... double checking that no proxies were set (and they are not) but ... something about the VPN may cause it to take a long time to decide that? If that simple maybe some value needs to be cached and only re-checked every few minutes? 

At any rate, mostly wanted to document this work-around ... it has given me new faith that the b3 aggregator may be ok.

Comment 4 David Williams

2010-12-21 14:45:56 EST

I found another windows machine, with same VPN installed, and it, like my main linux desktop machine, did a 'verify' of indigo in about 5 minutes. I confirmed all the settings between the two VPNs were the same. So, as next step, I completely uninstalled VPN on "slow machine" and re-installed it, and now all is well. That machine too now verifies in about 5 minutes. 

So, not sure what was wrong with other VPN install and not confident it won't come back with some update, or something. And not sure there is not some subtle interaction of "aggregator code" with VPN details, but ... seems mostly some issue with my installation of VPN (it was "AT&T Network Client (for IBM) version 7.6.3", if anyone needs to know in comparing other cases). So ... glad to close this now as "not eclipse" as the main problem ... hour long 'verify' operations ... is no longer a problem ... even though not sure exactly what was wrong. 

Thanks all,

Comment 5 David Williams

2016-09-16 15:59:25 EDT

[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI.
No change to assignee for resolved and verified bugs.]