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: Java heap space | ||
---|---|---|---|
Product: | connecteddeveloper | Reporter: | Jan Becicka <jbecicka> |
Component: | Bugzilla | Assignee: | Tomas Stupka <tstupka> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | olangr |
Priority: | P2 | Keywords: | PLAN |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | 161648 |
Attachments: | stacktrace |
Description
Jan Becicka
2009-11-09 03:40:36 UTC
Created attachment 90585 [details]
stacktrace
reproducible on netbeans.org I have heapdump (500M) if you want I'm member of Connected Developer IDE Contrib Editor Java I'm member of ConnectedDeveloper, Debugger, GUIBuilder, Performance and VersionControl - all together about 1,500 open issues. It took a while - cca 2-3 minutes, but all issues downloaded without a problem. It seems all is run again after restart, taking the same time... Isn't anything supposed to be cached here? Trying to open Java and expand Issues node shows 2274 issues after several minutes, now having close to 4,000 issues, together taking up ~250MB heap space. It's not so bad, but we can definitely get out of memory with loading too many issues. The question is whether we can efficiently obtain the number of issues without getting the whole list. Then we can put in place some limit and don't run queries with high number of results unless explicitly opened by the user. see two problems at the moment: - too much memory consumed - too many issues in this universe. need some reasonable limits... > Trying to open Java and expand Issues node shows 2274 issues after several > minutes, now having close to 4,000 issues, together taking up ~250MB heap > space. It's not so bad, still, we should investigate if there's no leak > The question is whether we can efficiently obtain the number of issues without > getting the whole list. yes. > Then we can put in place some limit and don't run > queries with high number of results unless explicitly opened by the user. xdesign on cc. > It seems all is run again after restart, taking the same time... Isn't anything
> supposed to be cached here?
no. nothing a query rerun would benefit from
The main problem I see is, that memory is consumed right after login to netbeans.org, and user cannot avoid it. This is caused by tinny number in bug dashboard. We should either drastically decrease memory consumption (e.g. as mentioned above by obtaining the number of issues without getting the whole list.) or at least provide some option not to show bug numbers right after login. Changeset: c2e6abefe9c6 Author: Tomas Stupka <tstupka@netbeans.org> Date: 2009-11-10 16:42 Message: there will be no "All Issues" query for netbeans.org Issue #176189 - OutOfMemoryError: Java heap space > The main problem I see is, that memory is consumed right after login to netbeans.org, and user cannot avoid it.
fixed in #c2e6abefe9c6. Removed the "All issues" query from the nb.org dashboard as it doesn't make sense anyway.
main problem fixed -> P3
no leaking found - closed |