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 54064 - Evil error recovery in javagator
Summary: Evil error recovery in javagator
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Navigation (show other bugs)
Version: 4.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: David Simonek
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2005-01-27 08:48 UTC by Martin Matula
Modified: 2005-08-12 13:13 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Matula 2005-01-27 08:48:15 UTC
I noticed that ClassMemberModel.loadContents
starts a transaction and then does some work. If
the code in the transaction throws an exception,
this exception is catched (without being logged
anywhere) and then the code sleeps for 6000
milliseconds *without releasing the transaction lock*!
This may block some IDE operations (such as
invocation of a refactoring) for a long time and
is very annoying. Moreover it is not apparent that
some problem occurred, since the exception is not
printed out or logged! So, the IDE just seems very
sluggish without an apparent reason.
Comment 1 David Simonek 2005-01-27 13:10:13 UTC
OK, I'll add logging and releasing the transaction lock during
waiting. (this catching and waiting code was already written by Tim, I
never really understood it, but I expect that some nasty exceptions
came from mdr and this code was just a defense...)
Comment 2 _ tboudreau 2005-01-27 15:19:35 UTC
The delay dates to a time when I was getting tons of exceptions from JavaModel (mostly 
CME's) and had no info on how to avoid them.  Using the transaction lock should have cured 
the problem.

Might want to keep the retry-delay code, if we consider it normal for anything to signal 
unparsability by throwing exceptions;  at any rate, at the time, it was just a way to keep 
Navigator usable for downloaders without popping exception dialogs at random times.
Comment 3 David Simonek 2005-01-28 12:09:26 UTC
I decided to get rid of waiting cycles, I verified that JMI doesn't
use exceptions to tell me that source is unparsable.
Comment 4 David Simonek 2005-01-28 12:13:23 UTC
fixed in main trunk along with 54063:

/cvs/objectbrowser/navigator/javanavigation/src/org/netbeans/modules/javanavigation/ClassMemberModel.java,v
 <--  ClassMemberModel.java
new revision: 1.22; previous revision: 1.21

/cvs/objectbrowser/navigator/javanavigation/src/org/netbeans/modules/javanavigation/JUtils.java,v
 <--  JUtils.java
new revision: 1.14; previous revision: 1.13