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 229732 - Accessing file system in EDT: CloneableEditorSupport.notifyModified
Summary: Accessing file system in EDT: CloneableEditorSupport.notifyModified
Status: REOPENED
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 7.3
Hardware: All All
: P3 normal (vote)
Assignee: Miloslav Metelka
URL:
Keywords: PERFORMANCE
Depends on:
Blocks: 218138
  Show dependency tree
 
Reported: 2013-05-14 15:03 UTC by Egor Ushakov
Modified: 2013-09-16 05:50 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
stacktrace (3.77 KB, text/plain)
2013-05-14 15:03 UTC, Egor Ushakov 		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 Egor Ushakov 2013-05-14 15:03:03 UTC 
see attached stacktrace, on every file open we access fs in EDT
Comment 1 Egor Ushakov 2013-05-14 15:03:29 UTC 
Created attachment 134430 [details]
stacktrace
Comment 2 Egor Ushakov 2013-05-14 15:04:37 UTC 
Actually it happens not on file open, but on first modification.
Same for notifyUnmodified.
Comment 3 Miloslav Metelka 2013-08-28 14:12:50 UTC 
Querying file for writability upon first modification is inevitable - the modification should not proceed if the file is not modifiable.
Comment 4 Egor Ushakov 2013-08-28 14:20:42 UTC 
I totally agree that canWrite is inevitable on file modification, but performing that in EDT leads to the whole IDE freeze if the file is on slow NFS
Comment 5 Vladimir Voskresensky 2013-08-28 14:36:28 UTC 
Mila, is it possible to move initialization of "canWrite" status into "org.openide.text Editor Initialization" thread?
Comment 6 Miloslav Metelka 2013-09-15 21:30:47 UTC 
"canWrite" is part of checking whether the document can be modified by typing (and other actions) or not. CloneableEditorSupport.notifyModified() then reports whether the file can be modified or not and the typing action either succeeds or the modification is rejected.
In the past we had the state when we allowed the first modification to proceed while doing the check on the background (i.e. return true from CloneableEditorSupport.notifyModified()) and if "canWrite" fails we attempted to undo the document modification(s) that occurred in the meantime but there were numerous problems with that approach including the user-visible fact that the typed characters appear in the document and suddenly they dissapear.

IMO if the user starts typing to the document she wants to be sure that it can modify the document so she will wait for the first modification to proceed even in case if it takes a while. I can't imagine that the user would start typing and when seeing that "canWrite" takes a long time to proceed that she would switch to another document and start typing there in the meanwhile or do anything else in the IDE.

Alternatively we could consider switching to another concept and test writability on save but that would be a huge change to the IDE's infrastructure and IMHO many users would refuse such change.
Comment 7 Vladimir Voskresensky 2013-09-16 05:50:18 UTC 
Mila, thanks for the answer. I don't think we should switch concepts. 
We already have "initializing document" phase and EDT phase.
It was interesting for me to know if "read only" state initialization can be moved into "initializing document".