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.
- Start IDE with fresh userdir; - Open j2se project; - Close Task window after it appears Scanning will go and memory will grow enormously until OOME happens. I can reproduce it with a small project ( jEdit) on a machine with 2Gb RAM. If task window isn't closed - project happily opens without any memory growth. 200904070200 jdk 1.6.0_12 WinXP SP2 but seen it on solaris and linux as well.
Created attachment 79647 [details] log file
it's regression and that's the reason for recent automated test failures - in tests we open j2se projects and close task window. Workaround is not to close task window.
it's a problem with EJBVerificationTaskProvider. it unnecessarily recompiles every java source files provided from task list infrastructure. it should subclass PushTaskScanner instead of FileTaskScanner and use the new indexing api to cache scanned tasks. a short term workaround is turning this task provider off in task list window.
Tomasz Slota originally implemented this feature, reassigning. There are known performance problems with the EJB verification, and my impression was that is is already turned off by default, isn't it? It is turned off for me in my build. How did it get activated in your testcase?
BTW, I saw that inner class EJBProblemFinder.RescanTrigger is unused - it probably should be deleted?
The code seems to have changed a lot since I originally wrote it. Anyways, I will rewrite it to the new approach, hope it can be done for the beta.
Thanks. I would still like to know why this code is called if EJB tasks are turned off by default.
"Thanks. I would still like to know why this code is called if EJB tasks are turned off by default." - most likely because of issue #162076.
Btw. the same problem is with org.netbeans.modules.j2ee.jpa.verification.JPAVerificationTaskProvider.
Vita, thanks for the investigation. I suspected the JPA verification could have the same problem (and it is also turned off by default intentionally). Tomasz, when you look at the EJB verification problem, can you please also look at JPA? Thanks.
"If task window isn't closed - project happily opens without any memory growth." This is not true. As of 200904130201 anyway, the closing of the Task List window isn't required. Memory consumption is simply huge always on the initial scan of the projects. You don't need a particularly large project for this to happen.
I'm running 200904150201 now and I've increased my max heap to 1GB in the config file.. and still I run out of memory all the time... with 6.5 I would be comfortable with 300MB heap. This happens when switching project groups or any time I see the "Scanning projects..." message on the status bar.
*** Issue 162965 has been marked as a duplicate of this issue. ***
I think this should be a P1. It makes NetBeans nearly useless - not many users are going to want to hack their config file just so they can launch NetBeans the first time - assuming they have enough memory to make it past this problem.
The major problem was now fixed in issue 162076. Are you still running into problems, even if the "Persistence API Problems" and "EJB API Problems" items are disabled in tasklist filter? If you are, and turning these off does not help, then you are probably facing a different issue than reported here, and it would be great if you could file it as a separate ticket, with a few thread dumps and exception stack traces. Thanks.
The integration of EJB and JPA Verification with the task list is now completely disabled - it is only possible to see errors in the currently edited file. See issue 163916 http://hg.netbeans.org/web-main/rev/af5b9a27d3cb
*** Issue 163974 has been marked as a duplicate of this issue. ***
*** Issue 163404 has been marked as a duplicate of this issue. ***
*** Issue 163925 has been marked as a duplicate of this issue. ***
*** Issue 164735 has been marked as a duplicate of this issue. ***
*** Issue 165205 has been marked as a duplicate of this issue. ***
v. in 20090529