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.
Created attachment 118790 [details] Thread dump. NetBeans sometimes freezes when project properties is closing after JSF framework was added. It happens in automated tests. Suspicious seem for me thread "Editor Parsing Loop" and "Default Request Processor" (0x0c4b5970). Please, evaluate what is the problem. Product Version = NetBeans Platform Dev (Build 201204250400) Operating System = Windows 7 version 6.1 running on x86 Java; VM; Vendor = 1.7.0_03; Java HotSpot(TM) Client VM 22.1-b02; Oracle Corporation Runtime = Java(TM) SE Runtime Environment 1.7.0_03-b05
I'm afraid that comes first regression after fixing issue #210492. I didn't take a look on that deeply yet.
Martin I think that this has already been discussed at the end of the 7.1 release (see issue 204427). I've just took a quick look at the discussion there and the changes you've made as a fix for issue 210492 are reverting exactly the changes from the fix for 204427. Maybe Jesse's comment #25 in issue 204427 could help you with this.
(In reply to comment #2) > Martin I think that this has already been discussed at the end of the 7.1 > release (see issue 204427). > I've just took a quick look at the discussion there and the changes you've made > as a fix for issue 210492 are reverting exactly the changes from the fix for > 204427. > > Maybe Jesse's comment #25 in issue 204427 could help you with this. Great memory, thanks. :) I knew that I already solve it somewhere. But the problem stays the same, probably it's worse now. :/ By running outside AWT EDT it causes deadlocks, by running it in AWT leads to LowPerformance exceptions (probably without big impact - but freezes the progress bar). Rest of the issue lies between locks of Projects and Editor APIs where we didn't hit consensus... I'll try to talk more with owners of those APIs.
Ye, I don't think we can do much about it on our side. Actually the same thing is done in the Maven projects (performing the same code in the AWT), only there is no Low performance issue so far :]
Yeah, this sucks. Putting on brainstorming hat: what about running framework extenders in separate request processor? The problem is that currently they are run from a thread which holds write access on Project.MUTEX. Posting them somewhere else (in the past it was AWT and that solved the issue but caused low performance problems) could do the trick, no? Framework extenders then could run some operations under their own Project write access but would have a chance to run code like "SpringWebModuleExtender$CreateSpringConfig.createFromTemplate" or "JSFPaletteUtilities.reformat" outside of any lock and therefore avoiding opportunity for deadlock.
(In reply to comment #5) > Yeah, this sucks. Putting on brainstorming hat: what about running framework > extenders in separate request processor? The problem is that currently they are > run from a thread which holds write access on Project.MUTEX. Posting them > somewhere else (in the past it was AWT and that solved the issue but caused low > performance problems) could do the trick, no? Framework extenders then could > run some operations under their own Project write access but would have a > chance to run code like > "SpringWebModuleExtender$CreateSpringConfig.createFromTemplate" or > "JSFPaletteUtilities.reformat" outside of any lock and therefore avoiding > opportunity for deadlock. Yeah, I though about something similar (or probably the same with implemented another progress bar to let user know what happens then - frameworks extending). I'll try some prototyping and attach the patch then. Thanks.
Created attachment 118859 [details] patch v1 Please could you take a look on that? If we would agree with that I would do the same changes for maven projects. Additionally I will check extends methods of all Web Frameworks whether they do everything project related under project mutex. After saving project properties... a) some framework added - progress bar always shows information that the project is exending for frameworks (and also saves the old ones) b) some frameworks are already included - save them, but show the progress dialog a little bit later (it should prevent blinking of dialogs - especially by no changes) c) else do nothing
Overall the patch looks OK. I'm not sure that added code complexity to avoid flickering is worth it. Do you think it is necessary to show progress dialog to user? Could we just show nothing and do it on background? Saving should be always quick and extending project with new framework happens once or twice in a lifetime of project.
(In reply to comment #8) > Overall the patch looks OK. I'm not sure that added code complexity to avoid > flickering is worth it. Do you think it is necessary to show progress dialog to > user? Could we just show nothing and do it on background? Saving should be > always quick and extending project with new framework happens once or twice in > a lifetime of project. Yeah, I think that showing the dialog is the correct way. I had something similar at TimerSessionBean that it was completed in RP and it looked really awful (which didn't like also JirkaS) and it was the smallest change which could happen. So although adding happens just once/twice per project. I would stay with the progress dialog. Regarding saving there can be another then our bundled framework which requires more time and also our JSF framework needs quite a much of time when some component suite is adding or removing (save can be doing the same changes as at Web Framework). BTW, I started with the simplest possible patch, but it didn't look well - the final patch is the result of my testing of all variants which crossed my mind.
At least add some comments describing the convoluted logic of the code.
(In reply to comment #10) > At least add some comments describing the convoluted logic of the code. I included as much comments as possible and updated the patch a little bit (smaller optimalization + fixes). MartinJ as you agreed I adapted the change also for maven projects, so please check that change if you are insterested in, thanks a lot. Should be fixed in web-main #ba945984a7c5.
It looks awesome Martin! ;]
Integrated into 'main-golden', will be available in build *201205040400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/ba945984a7c5 User: Martin Fousek <marfous@netbeans.org> Log: #211768 - Freeze when adding JSF framework to project