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 77557 - Long delays in some id operations while debugging apps
Summary: Long delays in some id operations while debugging apps
Status: CLOSED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Code (show other bugs)
Version: 5.x
Hardware: All Linux
: P2 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords: PERFORMANCE
: 87026 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-06-08 05:32 UTC by manawiz
Modified: 2010-04-29 09:29 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Two thread dumps in frozen state (117.49 KB, text/plain)
2006-06-09 01:40 UTC, manawiz
Details
Thread dumps of NB in the frozen state (109.46 KB, text/plain)
2006-06-11 00:33 UTC, manawiz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description manawiz 2006-06-08 05:32:25 UTC
When debugging one or more applications from within Netbeans, the ide frequently
freezes for 10-20 seconds.  During this time the cpu, disk and other resources
are idle.  The problem is exacerbated by running multiple applications
simultaneously.

I frequently run a tomcat based client app communicating with a separate axis2
soap based server app (using axis2 built-in http listener).  While debugging
both apps, the ide goes to sleep for no reason for 10+ seconds at a time
frequently, especially with operations that involve creating new tabs (e.g.,
opening a class) or switching tabs.  The problem occurs even when the server app
is run externally using nb jpda to connect to it.

No other applications on the machine experience this issue, so I believe it is
an nb problem.

Has anything like this been seen -- is there some workaround to try?
Comment 1 Antonin Nebuzelsky 2006-06-08 09:31:51 UTC
Reassigning to debugger team for evaluation.
Comment 2 Martin Entlicher 2006-06-08 11:20:38 UTC
A full thread dump when the IDE is frozen is necessary to see what's going on.
Please generate the thread dump via CTRL-\ in the console and attach it to this
issue. Thanks.
Comment 3 manawiz 2006-06-09 01:40:26 UTC
Created attachment 30905 [details]
Two thread dumps in frozen state
Comment 4 manawiz 2006-06-09 01:41:34 UTC
I've attached a file with two thread dumps.  I believe nb was in the frozen
state for both, and am certain it was in the frozen state for the second.

Thanks for looking at this,

Chuck
Comment 5 Petr Nejedly 2006-06-09 10:25:02 UTC
I see only thread dumps of the debugged application, not thread dump of the
frozen IDE.
Comment 6 manawiz 2006-06-11 00:33:23 UTC
Created attachment 30946 [details]
Thread dumps of NB in the frozen state
Comment 7 manawiz 2006-06-11 00:34:40 UTC
nbfreeze.txt has 4 thread dumps.  All 4 should be in the frozen state; I am
certain that the fourth is in the frozen state.
Comment 8 Roman Ondruska 2006-06-13 14:40:19 UTC
From the TD: Some NB threads are hanging in JDI code -> This is not a bug in NB.
We experienced JDI deadlocks with JDK 1.5 (and older), some of them should be
fixed in JDK 1.6. Please, try JDK 1.6, hope this will help. 
 
Comment 9 Jiri Kovalsky 2006-06-13 14:58:09 UTC
Verifying the issue as invalid. 
Comment 10 manawiz 2006-07-15 03:45:15 UTC
This bug renders netbeans unusable on linux.  Eclipse does not have this
problem.  Even if the issue is in JDI, it is a netbeans problem if you want to
supprot the linux platform.  I have been a netbeans user for a long time and
consistently recommend netbeans to others.  This is so exasperating I'm about to
give in and switch to eclipse.  Other developers who use eclipse laugh at me
when they see how unusable netbeans is for debugging on linux!  When the
condition arises, which frequently, every few seconds netbeans pauses for no
reason for 10 seconds.  This is ridiculous.

I cannot switch to jdk 1.6 as my project must deliver in 1.5.

Will netbeans 5.5 address this issue?  If I wanted to try it, is there a solid
verison yet?  I went through all the betas, rc's and many development builds
with 4.0.  I cannot afford that kind of time now and need to switch to a solid
environment.

Comment 11 Martin Entlicher 2006-07-17 11:01:18 UTC
manawiz, maybe you're encountering issue
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6401245
If so, you may consider to use J2SE 5.0 update 8 when it's available.

The slowness of repaints is caused by access to JDI in AWT-EventQueue. We'll
reschedule this to some other thread so that the GUI is not affected. However,
this will not affect the speed of the debugger itself. The performance can be
improved after issue #68381 and issue #46286 are fixed.
Comment 12 Martin Entlicher 2006-07-17 17:30:47 UTC
manawiz, we would like to know whether you're really encountering
bughttp://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6401245, or whether it's
something else. Can you please provide the kernel version? Can can you please
try to run "sudo sysctl -w net.ipv4.tcp_abc=0" as root as suggested in the bug
to see whether it solves the problem? Thanks.
Comment 13 manawiz 2006-07-18 08:35:34 UTC
Unbelievable difference!  I just went from hell to heaven.

I am running kernel 2.6.15 and the workaround of disabling Nagles Algorithm
appears to fully resolve my issue.  Unbelievable difference.

I've had only a short session today on Netbeans due to a busy schedule meetings,
but even with this session I'm confident this addressed the issue because the
performance is so dramtically different.

Many linux users are now on 2.6.15 or above.  I'd encourage you to do whatever
you can to get Sun to issue a fix before the Fall.

I'd suggest leaving this issue open so it easy for others to find until there is
a real fix.  I hope there are no adverse affects of disabling Nagles in 2.6.15.

Thanks much!
Comment 14 Jiri Kovalsky 2006-07-18 08:57:32 UTC
OK, in such case I am lowering priority of this issue to P2. Also adding JDK_1.5
keyword to reflect the fact that issue is JDK 1.5 specific.

Thanks a lot manawiz for the update !
Comment 15 Jiri Kovalsky 2006-07-18 08:59:23 UTC
Sorry, I didn't want to mark this as fixed. Don't know how this happened ... :-\
Comment 16 Martin Entlicher 2006-07-18 10:56:45 UTC
Thanks for the update. The bug in JDI will be fixed in J2SE 5.0 update 8, which
will be probably released in the fall 2006. We can not do anything more about
it, it's not a NetBeans fault.

I'm going to reschedule the JDI calls out of AWT-EventQueue to keep the GUI
responsive.
Comment 17 Martin Entlicher 2006-07-18 13:53:17 UTC
I've basically reverted the fix of issue #56053. It was really ugly and it hurts
performance, also JDI will not be accessed from AWT now. According to tests, the
actions behave as expected, so hopefully continuous poll of threads status is
not necessary.
Also, J2ME_DEBUGGER property is ignored now.

/cvs/debuggerjpda/api/arch.xml,v  <--  arch.xml
new revision: 1.13; previous revision: 1.12

/cvs/debuggerjpda/arch.xml,v  <--  arch.xml
new revision: 1.6; previous revision: 1.5

/cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/actions/ContinueActionProvider.java,v
 <--  ContinueActionProvider.java
new revision: 1.11; previous revision: 1.10

/cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/actions/PauseActionProvider.java,v
 <--  PauseActionProvider.java
new revision: 1.12; previous revision: 1.11
Comment 18 Jiri Kovalsky 2006-07-18 14:25:37 UTC
Now can you manawiz please verify the fix in tomorrow's daily development build
of NetBeans 6.0 ? We would truly appreciate your help here.
Comment 19 Martin Entlicher 2006-10-16 13:12:48 UTC
*** Issue 87026 has been marked as a duplicate of this issue. ***
Comment 20 Quality Engineering 2010-04-29 09:29:11 UTC
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.