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.
|Summary:||OutOfMemoryError: Huge EventControl during downloading of remote files|
|Component:||Filesystems||Assignee:||Jaroslav Havlin <jhavlin>|
|Issue Type:||DEFECT||Exception Reporter:||205099|
Description mathieu.e 2013-11-07 09:39:12 UTC
Build: NetBeans IDE 7.4 (Build 201310111528) VM: Java HotSpot(TM) 64-Bit Server VM, 24.0-b56, Java(TM) SE Runtime Environment, 1.7.0_40-b43 OS: Windows 8 User Comments: mathieu.e: After a restart. I had a message Stacktrace: java.lang.OutOfMemoryError: Java heap space at org.openide.filesystems.FileUtil.copy(FileUtil.java:543) at org.netbeans.modules.localhistory.utils.FileUtils.copy(FileUtils.java:145) at org.netbeans.modules.localhistory.store.LocalHistoryStoreImpl.storeChangedSync(LocalHistoryStoreImpl.java:212) at org.netbeans.modules.localhistory.store.LocalHistoryStoreImpl.access$400(LocalHistoryStoreImpl.java:82) at org.netbeans.modules.localhistory.store.LocalHistoryStoreImpl$3.run(LocalHistoryStoreImpl.java:188) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1432)
Comment 2 Tomas Stupka 2013-12-04 13:02:15 UTC
all that LH was doing at that place was to copy a file stream into another on respond on a FS event. FileSystems seem to hold a lot of resources - reassigning for further evaluation ...
Comment 3 Jaroslav Havlin 2013-12-05 12:27:44 UTC
In the heap dump, there's an org.openide.filesystems.EventControl instance with retained size of almost 500 MB. Method o.n.m.php.project.connections.RemoteClient.downloadFile() calls FileUtils.runAtomicAction. The action generates a lot of file change events, that are queued to be processed after the action is finished. Tomas, please, do you have any idea how this could be fixed in the PHP module? In filesystem, it could possibly be fixed by introducing some limit on the size of the queue. If this limit is reached, instead of using the queue, all files would be refreshed (with FileUtil.refreshAll()) after the atomic action is finished. But it would generate different sequence of file events. This solution needs to be evaluated and tested.
Comment 4 Tomas Mysik 2013-12-05 13:12:50 UTC
Unfortunately, I cannot see any easy fix/change that could be done in PHP module right now. Let's focus on it for the next NB version since workaround is "easy" (increasing memory limit). Thanks.
Comment 5 Jaroslav Havlin 2013-12-05 13:17:24 UTC
Thank you, Tomáš. > But it would generate different sequence of file events. There is quite a high risk of regressions. Mathieu.e, can you please try setting the Xmx parameter to some higher value, e.g. -J-Xmx1g See https://performance.netbeans.org/howto/jvmswitches/. Please let us know if it helps. Thank you very much for reporting.