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 238082

Summary: OutOfMemoryError: Huge EventControl during downloading of remote files
Product: platform Reporter: mathieu.e
Component: FilesystemsAssignee: Jaroslav Havlin <jhavlin>
Status: NEW ---    
Severity: normal CC: tmysik
Priority: P3    
Version: 7.4   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter: 205099
Attachments: stacktrace

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 1 mathieu.e 2013-11-07 09:39:14 UTC 
Created attachment 141931 [details]
stacktrace
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.