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 43213 - Avoid ModuleInstall class
Summary: Avoid ModuleInstall class
Status: CLOSED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: HTTP Monitor (show other bugs)
Version: 4.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Petr Jiricka
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2004-05-13 15:27 UTC by _ rkubacki
Modified: 2006-03-24 09:58 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Patch for this issue (4.31 KB, patch)
2005-03-18 17:24 UTC, Petr Jiricka 		Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2004-05-13 15:27:51 UTC 
It should be enough to do cleanup of old stored
data before monitor is used in next session. Using
this approach ModulIstall class can be avoided -
less classes loaded on start / faster shutdown.
Comment 1 Ana.von Klopp 2004-05-26 17:55:52 UTC 
That means that potentially a large number of files will hang around 
until the user uses the IDE next time. 

I can look into it though if that's considered an acceptable 
side-effect.
Comment 2 _ rkubacki 2004-05-26 18:08:03 UTC 
I don't think it is a problem - IDEA requires ~200MB for caches to
store parsed projects. Our MDR will use tens of megabytes too. 

Any estimation how data can monitor store?
Comment 3 Sherold Dev 2005-03-18 14:41:37 UTC 
Setting the TM to 4.1.
Comment 4 Petr Jiricka 2005-03-18 17:23:16 UTC 
I have a patch for this. Radim and Stepan, please comment.

I wanted to avoid the need for the progress dialog at all, so the user is not
aware of this. Also, I did not want to eagerly delete the records on startup
whenever the monitor window is open (which it usually is, when you develop and
deploy webapps). Still, didn't quite succeed. 

I took the approach of filtering out the records based on file timestamp, so
this does not slow down the creation of monitor view. The old entries are then
deleted ibn the background.
Comment 5 Petr Jiricka 2005-03-18 17:24:16 UTC 
Created attachment 20960 [details]
Patch for this issue
Comment 6 _ rkubacki 2005-03-18 17:47:53 UTC 
What yo mean by didn't quite succeed?

Should not we get (and delete) transactions in TransactioView.open() before we
call super.open()? The patch looks good IMO.
Comment 7 Petr Jiricka 2005-03-19 06:05:05 UTC 
Fixed.

Checking in manifest.mf;
/cvs/monitor/manifest.mf,v  <--  manifest.mf
new revision: 1.25; previous revision: 1.24
done
Removing src/org/netbeans/modules/web/monitor/MonitorModule.java;
/cvs/monitor/src/org/netbeans/modules/web/monitor/MonitorModule.java,v  <-- 
MonitorModule.java
new revision: delete; previous revision: 1.7
done
Checking in src/org/netbeans/modules/web/monitor/client/Controller.java;
/cvs/monitor/src/org/netbeans/modules/web/monitor/client/Controller.java,v  <--
 Controller.java
new revision: 1.33; previous revision: 1.32
done
Checking in src/org/netbeans/modules/web/monitor/client/MonitorAction.java;
/cvs/monitor/src/org/netbeans/modules/web/monitor/client/MonitorAction.java,v 
<--  MonitorAction.java
new revision: 1.15; previous revision: 1.14
done


"What yo mean by didn't quite succeed?" - I think the nodes are created eagerly
whenever the monitor window is open after restart (even not fronted).
Comment 8 _ rkubacki 2005-03-23 13:10:41 UTC 
verified