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 227640 - IndexingSupport.markDirtyDocuments accessess disk from within document write lock
Summary: IndexingSupport.markDirtyDocuments accessess disk from within document write ...
Status: RESOLVED WONTFIX
Alias: None
Product: editor
Classification: Unclassified
Component: Parsing & Indexing (show other bugs)
Version: 7.2
Hardware: All All
: P3 normal (vote)
Assignee: Svata Dedic
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2013-03-18 19:27 UTC by Exceptions Reporter
Modified: 2016-07-07 07:29 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 199565

Attachments
nps snapshot (219.27 KB, application/nps)
2013-03-18 19:28 UTC, Exceptions Reporter 		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 Exceptions Reporter 2013-03-18 19:27:57 UTC 
Build: NetBeans IDE 7.2 (Build 201207171143)
VM: Java HotSpot(TM) 64-Bit Server VM, 20.1-b02, Java(TM) SE Runtime Environment, 1.6.0_26-b03
OS: Windows 7
Maximum slowness yet reported was 65712 ms, average is 34502
Comment 1 Exceptions Reporter 2013-03-18 19:28:02 UTC 
Created attachment 132770 [details]
nps snapshot
Comment 2 Svata Dedic 2013-05-31 09:02:11 UTC 
#667303: Sadly the filesystem layer is blocked on File.exists() for 190seconds; subsequently the EDT blocks waiting for filesystem access

#665593: The same reason as above, WinNT filesystem blocks for 55 seconds on File.exists or File.isDirectory

#665819: the profiling data does not show any errors IMHO. The CC delay is caused by searching for JSF composites, and most probably because of an issue in Win I/O the index search takes 230ms. Will forward to J2EE/JSF

#664583: older implementation of handleDocumentModification, but similar to 667303 tries to access disk in order to actually ecord some dirty keys into in-memory Set.

In all those cases the reason is that AtomicLockListener implemneted by RepositoryUpdater is run synchronously in the EDT and it blocks on filesystem access (the filesystem layer is blocked by native OS in other thread). Invalidation (or at least raising an invalid flag) should be synchronous I think, so the initial idea to spin off the markDirty is not the way.

The access to filesystem layer could be postponed in Lucene support until first 'real' operation. It will not however solve the problem of slow and blocking Win I/O, only makes it less visible.
Comment 3 Martin Balin 2016-07-07 07:29:04 UTC 
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss