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 177148 - Too much FS refreshing (AWT thread blocked for 148088 ms.)
Summary: Too much FS refreshing (AWT thread blocked for 148088 ms.)
Status: RESOLVED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Maven (show other bugs)
Version: 6.x
Hardware: All All
: P3 normal (vote)
Assignee: David Konecny
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2009-11-18 18:15 UTC by tveimo
Modified: 2010-11-04 20:48 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 162464

Attachments
nps snapshot (256.00 KB, application/nps)
2009-11-18 18:15 UTC, tveimo 		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 tveimo 2009-11-18 18:15:15 UTC 
Build: NetBeans IDE 6.8 Beta (Build 200910212001)
VM: Java HotSpot(TM) Client VM, 14.1-b02-90, Java(TM) SE Runtime Environment, 1.6.0_15-b03-219
OS: Mac OS X, 10.6.2, i386
Maximum slowness yet reported was 148088 ms, average is 148088
Comment 1 tveimo 2009-11-18 18:15:20 UTC 
Created attachment 91300 [details]
nps snapshot
Comment 2 Antonin Nebuzelsky 2010-07-30 15:17:42 UTC 
Reassigning to default owner.
Comment 3 Antonin Nebuzelsky 2010-11-03 09:36:29 UTC 
Thread "AWT-EventQueue-1" is repainting main window and all its contents which is hanging in
o.n.m.maven.hints.pom.StatusProvider$StatusProviderImpl.getUpToDate()
-> org.openide.loaders.DataObject.find()
 -> org.openide.loaders.DataObjectPool.find()
  where it is waiting to enter synchronized block on DataObjectPool object

All the other activity gathered in the snapshot shows that a way too much filesystem refreshing is running in several threads concurrently. And the threads are blocking each other repeatedly in synchronized accesses to various FS/DO related methods, e.g.
o.n.m.masterfs.filebasedfs.fileobjects.FileObjectFactory.getCachedOnly()
o.n.m.masterfs.filebasedfs.fileobjects.FileObjectFactory.collectForRefresh()

* thread "FileUtil-Refresh-All" refreshing all known files after NB main window got focus (thread "Refresh-After-WindowActivated" is waiting for the refresh to finish)

* thread "Subversion - file status refresh"

* thread "Default Request Processor" running a maven goal and calling org.netbeans.core.NbTopManager$NbLifecycleManager.saveAll() first which is also refreshing status of some files

* thread "exec_Run preniro_17" which prepares for deploy operation in
org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy() by calling into org.openide.filesystems.FileUtil.refreshFor()

The aggressive refresh of all known files is fixed in 7.0 with the native filesystem listeners.

A question here is if org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy() needs to be calling FileUtil.refreshFor().

Reassigning to javaee/maven for evaluation of this last point. Otherwise, the issue can be closed in 7.0.
Comment 4 David Konecny 2010-11-04 20:48:10 UTC 
(In reply to comment #3)
> A question here is if
> org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy() needs to be
> calling FileUtil.refreshFor().

I have no idea. I'm guessing that reason for that call is to make sure that any external modifications of Maven config files are used for deployment.

If there is a strong performance reason to remove that code then I would remove it. I think it should be safe. And if not then users would speak up and at least we would know what is it there for. For now I'm leaving this as is.