Community
Participate
Working Groups
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,
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.
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?
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.
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,
[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI. No change to assignee for resolved and verified bugs.]
