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.

Bug 174143 - [68cat] AWT thread blocked for 3963 ms.
Summary: [68cat] AWT thread blocked for 3963 ms.
Status: VERIFIED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Jan Lahoda
URL: http://statistics.netbeans.org/except...
Keywords:
: 174140 174218 174219 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-10-08 17:57 UTC by Michel Graciano
Modified: 2009-11-12 10:03 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 159291

Attachments
nps snapshot (256.00 KB, application/nps)
2009-11-12 10:03 UTC, ravindranathakila 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Michel Graciano 2009-10-08 17:57:30 UTC 
Build: NetBeans IDE Dev (Build 200910070250)
VM: Java HotSpot(TM) Client VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01
OS: Linux, 2.6.28-15-generic, i386
User comments: 
Maximum slowness yet reported was 7953 ms, average is 5958
Comment 1 Jan Lahoda 2009-10-09 12:28:31 UTC 
Hanzi, I am sorry, but this is caused by:
http://hg.netbeans.org/main-silver?cmd=changeset;node=b90be0d4ad5e

ElementNode$Description.getFileObject() calls SourceUtils.getFile() for inherited members and this method is not very
fast and should not be called synchronously (esp. not for a lot of nodes).

I do not see a nice solution to this, which would not regress (too much) on issue #168738 (even the short one-file scans
can cause ElementOpen to jump to the beginning of file instead of correct offset) and issue #160478.

The most reasonable solution I see is to make ElementOpen.open wait a little while (1s?) for the scan to finish. If the
scan would finish quickly, exact offset would be used. Otherwise, offset 0 would be used. Possibly, the little while
could be slightly longer if the EO.open would be invoked outside AWT.

Also, navigator should probably use RunOffAWT, but that currently would not solve #168738.

Any opinions?
Comment 2 Tomas Zezula 2009-10-09 12:35:50 UTC 
I have no other solution for NB 6.8.
I am playing with transactional lucene index and possibility to run background scan parallel to TaskProcessor, but it will take a time....
Comment 3 Jan Lahoda 2009-10-09 13:29:21 UTC 
*** Issue 174218 has been marked as a duplicate of this issue. ***
Comment 4 Jan Lahoda 2009-10-09 14:08:03 UTC 
I going to try to implement this.
Comment 5 Jan Lahoda 2009-10-09 14:08:21 UTC 
*** Issue 174140 has been marked as a duplicate of this issue. ***
Comment 6 Jan Lahoda 2009-10-09 14:09:44 UTC 
*** Issue 174219 has been marked as a duplicate of this issue. ***
Comment 7 Jan Lahoda 2009-10-11 22:32:04 UTC 
When scan is in progress, ElementOpen.open waits for 1s/2s (AWT/non-AWT) now:
http://hg.netbeans.org/jet-main/rev/7712dbf61d62

Lets see how this is going to work.
Comment 8 Michel Graciano 2009-10-12 00:17:11 UTC 
As soon as new build is available I will try it. Thanks for your effort.
Comment 9 Quality Engineering 2009-10-14 10:56:10 UTC 
Integrated into 'main-golden', will be available in build *200910140201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/7712dbf61d62
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #168738, #174143: if indexing is running, ElementOpen.open should wait for a while before giving up and jumping to offset 0. Navigator should not call Description.getFileObject/SourceUtils.getFile synchronously for all nodes.
Comment 10 Michel Graciano 2009-10-14 14:43:19 UTC 
Looks pretty good now.
v. 200910140201
Comment 11 ravindranathakila 2009-11-12 10:03:22 UTC 
Created attachment 90923 [details]
nps snapshot