Bug 177148 - Too much FS refreshing (AWT thread blocked for 148088 ms.)
Too much FS refreshing (AWT thread blocked for 148088 ms.)
Status: RESOLVED FIXED
Product: javaee
Classification: Unclassified
Component: Maven
6.x
All All
: P3 (vote)
: 7.0
Assigned To: David Konecny
issues@javaee
EXCEPTIONS_REPORT perf-profileme
: PERFORMANCE
Depends on:
Blocks:
  Show dependency treegraph
 
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
:


Attachments
nps snapshot (256.00 KB, application/nps)
2009-11-18 18:15 UTC, tveimo
Details

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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo