Jim, reassigingin, I have a lot on my plate and I'm not that familiar with this
old code

Jim, reassiging, I have a lot on my plate and I'm not that familiar with this
old code

What makes this a P1?

I'm not familiar with this code, and I have no idea what it does, but I note
that the guidelines for P1 say:

- memory leak	
    - Huge memory leak
- performance 	
    - Very bad UI responsiveness making the feature unusable
    - Scalability problem making the feature unusable in an usual scenario 

Does our problem match these?  Can you tell me how many of these objects are
typically created?

These objects hold onto WebProject objects, each of which correspond to a single
project.  This list holds every single WebProject, which by itself is a fairly
significant leak.  

However, there is other code that relies on the lifecycle of the WebProject
objects to be correct (namely WeakHashMap<WebProject, ...> objects).  These
cause insync and designer artifacts to remain in memory after they are discarded.

I committed a fix that changes the listener to use Weak References. 
More work may be needed

There are still some static reference to WebProjects but not sure yet how to
resolve this.

To Jim: given how eager current vw support is I'd say that leaking web projects
are fairly important problem as it makes it impossible to switch freely between
VW projects.

Yet another note - this code can easily cause problems in unrelated parts of IDE
as it usually keeps all projects (VW as well as JavaSE/JavaEE/JavaME/UML/...)

Created attachment 42935 [details]
ProjectDataSourceTracker diff

See previous attached diff for the useful suggestions by Radim:

"Adding suggestions from Radim:
"> -    Set listeners = new HashSet();
> +    Set listeners = new HashSet<WeakReference>();

private Set<Reference<ProjectChangeListener> listeners = new
HashSet<Reference<ProjectChangeListener>>();

is what you want. And it will yell at you that #removeProjectChangeListener is
currently wrong as the code is adding *reference* to PCL but removing the
listener itself.

>      private Project previousProject = null;
>      private static boolean datasourcesUpdated = false;
>      private OpenProjectDetector openedProject;
> @@ -91,7 +91,7 @@
>              ProjectChangeEvent evt = new  ProjectChangeEvent(project);
>              Iterator iter = listeners.iterator();
>              while(iter.hasNext()) {
> -                ((ProjectChangeListener)iter.next()).projectChanged(evt);
> +               
((ProjectChangeListener)((WeakReference)iter.next()).get()).projectChanged(evt);
>              }
for (Reference<ProjectChangeListener> ref: listeners) {
    ProjectChangeListener pcl = ref.get();
    if (pcl != null) {
        pcl.projectChanged(evt);
    }
}

If you use java.lang.ref.Reference then you have to check it the object was
garbage collected! "

I will switch to WeakReferences or similar.

However, that's probably not the right long-term solution.  The right way is to
remove the DSTracker objects from the trackers list whenever the corresponding
project is closed.  Can you tell me how to listen for project closing?  This
used to be quite awkward in earlier versions of NB, but maybe there's a cleaner
way now.

The WeakReferences approach turned out to be complicated, because of the need to
hunt down and weaken all places that referenced the Project.  It was easier to
Do The Right Thing, which was to add a listener for Project closing events, and
remove the corresponding DSTracker at that time.

Marking this fixed; please reopen if there is still an issue.

The WebProject objects do not appear to leak from this class any longer.  This functionality needs to be verified to
ensure that it still works as expected though.

Verified.

A new round of memory tests indicate that the ProjectDataSourceTracker class is leaking WebProject objects again.  The
memory leak was fixed in revision 1.8 (for ProjectDataSourceTracker.java), but revision 1.9 removed the code that
maintained the trackers map.

Restored previous fixes. My mistake, I don't know why I had commented out the fixes

Checking in
visualweb/dataconnectivity/src/org/netbeans/modules/visualweb/dataconnectivity/project/datasource/ProjectDataSourceTracker.java;
/cvs/visualweb/dataconnectivity/src/org/netbeans/modules/visualweb/dataconnectivity/project/datasource/ProjectDataSourceTracker.java,v
 <--  ProjectDa
taSourceTracker.java
new revision: 1.13; previous revision: 1.12
done

Verified.