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 249196 - org.openide.nodes.FilterNode.getActions: LowPerformance took 43108 ms.
Summary: org.openide.nodes.FilterNode.getActions: LowPerformance took 43108 ms.
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Data Systems (show other bugs)
Version: 8.0
Hardware: All All
: P3 normal (vote)
Assignee: Jaroslav Havlin
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2014-12-08 10:46 UTC by Exceptions Reporter
Modified: 2015-08-27 12:35 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 213978


Attachments
nps snapshot (61.98 KB, application/nps)
2014-12-08 10:46 UTC, Exceptions Reporter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Exceptions Reporter 2014-12-08 10:46:41 UTC
This bug was originally marked as duplicate of bug 238381, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related.

Build: NetBeans IDE 8.0.1 (Build 201408251540)
VM: Java HotSpot(TM) Client VM, 25.20-b23, Java(TM) SE Runtime Environment, 1.8.0_20-b26
OS: Windows 7

User Comments:
GUEST: ?? ??????????? ???????? ????? ?? ?????? ? ???????(fx) ?????? ???? ? ??????? main, ????????? ???????? ????? ??????? ????????? ???? ???? ? ?????????????? ????.



Maximum slowness yet reported was 43108 ms, average is 43108
Comment 1 Exceptions Reporter 2014-12-08 10:46:43 UTC
Created attachment 150952 [details]
nps snapshot
Comment 2 Ondrej Vrabec 2015-03-06 12:01:22 UTC
... the almost DL in org.openide.loaders.FolderLookup$ProxyLkp.beforeLookup() - uses timed wait but is called 3-4 times in a row so blocks the IDE anyway.
Comment 3 Jaroslav Havlin 2015-08-26 15:23:53 UTC
Thread "Pasting":
DataObject.copy calls DataObjectPool.runAtomicAction, which enters "recognition".
Inside it, Lookup.forPath().lookupAll() is called (to get Loaders for the MIME type), which waits for Folder Recognizer's finish (it is a folder lookup).

Thread "Folder Recognizer":
It read files describing Loaders for the MIME type, but it needs to call DataObjectPool.findDataObject and to wait until the "recognition" lock is released. Deadlock.
Comment 4 Jaroslav Havlin 2015-08-27 12:35:44 UTC
The explanation in comment 3 is probably incorrect, I cannot create a test case for it. 

More likely, "Folder Recognizer" task for the target directory (of the copy operation) cannot be finished because the copy operation's atomic action has "locked" DataObjectPool (maybe the copy operation and recognizer started almost in parallel). The "Folder Recognizer" RequestProcessor is blocked, so getting of DataObject.Factory instances from config filesystem cannot even start. Thus, the copy operation cannot also finish, because it needs the factories for copied DataObjects. -> Deadlock.
Other threads that wait for some FolderList tasks (queued in "Folder Recognizer" processor) are also blocked.