This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I've updated my daily build yesterday (updating regularly, but beeing for vacation last week, so there shouldn't be any problems with state of already installed modules). 2 modules have been updated (both sth. about autoupdate, probably UI and libs). My problem: After the update, the IDE hangs, if I want to update more. Probably it would come back to life again after several hours. However, I won't wait for my computer for such a long time. Especially, after the update I get a notification about unresolved dependencies (though dependencies the IDE should be correct - seems they're checked against plugins on deadlock server. I've got this problem at several times, but could always work around it - up to now). Clicking "No" leaves my notebook in "time consuming" state, i.e. NB uses all the available CPU time. Trying to update then, but Plugins tool does never stop, never getting a list shown of available plugins. When resolving dependencies, several modules are loaded, Java must be disabled to start NB, but again NB hangs and I cannot activate Java again. Seems, the updated Autoupdate causes a thread to permanently run and grab all the CPU time needed, probably even (re-)starting the thread because of a wrong condition.
Hm, seems to be some "co-working" with another update (probably dialogs api?): When trying to update plugins in a non-updated daily build (which still is using the one-week-ago updated modules), the plugin dialog hangs, too, while the IDE itself runs without pain.
Created attachment 107943 [details] IDE log The log seems to have much related data. Especially the incomplete URLs (ports without host) are very suspicious - what might have caused the corrupted data?
While aborting autoupdate after an hour up to now, I've started plugin window yesterday morning and left my notebook running till evening. Could update 29 modules then. After the update, NB seems no more to completely block, but still runs slow. Probably too many tests running inside autoupdate? BTW, "Resolve missing modules" seems to check dependencies using server provided modules instead of local ones, possibly related?
Found out, that there were two problems: 1. Autoupdate much too slow. 2. Java modules now depend on parsing.lucene/2, but spec versions seem not to be upgraded, caused dependency problems. [1] 1. Don't know, how AU works - where is the algorithm for dependency checking? Just would like to have a look at it. 2. As I don't know how it works, I've to ask some questions about it: - How are dependencies checked? Do You ask the server for each module to send You a separate file? Or do You fetch the whole bunch of data at once? The latter would cause less server load and will take take less time, as connection establishment is needed only once. - Local module dependencies seem to be looked for by requests to module core - they should be gotten by some background task and stored locally (so memory needs not to be used the whole time, if no updates are to be fetched). As updating the local file is error prone, the file should probably be built at startup time or when calling "Resolve missing modules". [2] Java team seems to have a policy of only updating spec versions after serious changes, they obviosly do not change the spec version after dependencies updates, which sometimes results in an unusable IDE. It would be fine to also check the build date and/or, better, a hash code/CRC on manifest and project.xml files, so dependency changes could be detected. While the second bug does not directly belong to AU, it will be a good workaround for those IDE-broken-by-spec bugs. I've considered a second bug/enhancement report, but IMHO it will be easier to fix it in the same step as working on the first (expecting You'll work on the same piece of code).
As I could current work around the problem (though having to spend several hours, needing to uninstall and reinstall Java modules), reducing to P2, while IMO P3 would be too low. Problem should be addressed shortly, because users need trustworthy update functionality, not sth. that corrupts their most important tool.
Failed to parse http://people.freenet.de/ramon.ramos/nb/updates.xml is likely the slowness problem. Consider removing the broken update center URL. Should you have any other slowness inquiries, please attach profiler snapshot. It is said that update of parsing.lucene/2 broke your userdir, but it is just a bug in development version, not in final product, and as such, it is not P2 at all. I am closing as wontfix. I would reassign, but the report is so complicated that I cannot find a single category where it would belong.