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: | OOME due to profiler wrong usage of RP | ||
---|---|---|---|
Product: | profiler | Reporter: | Jaroslav Tulach <jtulach> |
Component: | Base | Assignee: | issues@profiler <issues> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | issues |
Priority: | P1 | Keywords: | PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Thread dump |
Description
Jaroslav Tulach
2007-04-09 18:03:32 UTC
Created attachment 40630 [details]
Thread dump
To the contrary, I'd say that the profiler's wrong usage of RP (which is already reported and fixed, see issue 100077) is NOT the cause of the OOME. Heap dump, or at least histogram (cf. jmap) would be much more usable in identifying the culprit. Needless to say that without profiler cluster everything works. I've never anticipated that the infrastructure would block all simple read only queries till the scan is done. However, profiler now uses it's own instance of RequestProcessor (see issue 1000077) with 2 threads in pool so it should never happen again that there will be 50 threads spawned in profiler. The OOME might be caused by an excessive usage of threads, indeed. I've never anticipated that the infrastructure would block all simple read only queries till the scan is done. However, profiler now uses it's own instance of RequestProcessor (see issue 1000077) with 2 threads in pool so it should never happen again that there will be 50 threads spawned in profiler. jtulach, could you please verify this issue or provide detailed instructions how to reproduce it |