Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 358999

Summary:

Deleting multiple connections takes long time

Product:

[Tools] Target Management

Reporter:

Masao Nishimoto <e03616>

Component:

RSE

Assignee:

David McKnight <dmcknigh>

Status:

RESOLVED FIXED

QA Contact:

Martin Oberhuber <mober.at+eclipse>

Severity:

normal

Priority:

CC:

dmcknigh, kenya

Version:

3.2.2

Target Milestone:

3.4 M3

Hardware:

OS:

Windows XP

Whiteboard:

Bug Depends on:

Bug Blocks:

359566

Attachments:

Description	Flags
patch to only create reference when it wasn't found originally	none

Description Masao Nishimoto

2011-09-27 01:47:25 EDT

1. Create 5 Linux connections, that can be dummy without verifying host name
2. Create one filter in Files and one filter in Processes for all connections
3. Select all connections and delete

It takes more than a minutes to finish.

- If no private filters exist, delete is fast.

In SystemFilterPoolManager.deleteSystemFilterPool, the number of referencing objects increases when:
1) the number of connections increases
   - if there is one connection, the number is 12 for Files and 21 for Processes.
   - if there are two connections, the number is 20 for Files and 37 for Processes.
2) one is deleted after another
   - if there are two connections, the numbers are 20 and 37 for the first connection, and they are 71 and 139 for the second connection.

Comment 1 David McKnight

2011-09-27 11:19:10 EDT

Created attachment 204095 [details]
patch to only create reference when it wasn't found originally

It looks like this came about as a result of a change introduced via bug 170932.  Every time SystemFilterPoolReference.getReferencedFilterPool() was called, it would create new reference, even if it wasn't needed:

public ISystemFilterPool getReferencedFilterPool() {
		ISystemFilterPool filterPool = (ISystemFilterPool) getReferencedObject();
		if (filterPool == null) {
                   ...
		}

		if (filterPool != null) { // called every time!
	-->>	  setReferenceToFilterPool(filterPool);
		  setReferenceBroken(false);
	        } else {
		  setReferenceBroken(true);
	        }
		return filterPool;
	}

I believe that the 2nd if needs to be inside the first if block so we don't end up creating tons of redundant references.

Comment 2 David McKnight

2011-09-27 11:19:31 EDT

Dave D, could you please review the patch?

Comment 3 David McKnight

2011-09-27 11:22:57 EDT

Masao, does this need to be backported to RSE 3.2.x or RSE 3.0.x?

Comment 4 Masao Nishimoto

2011-09-27 20:11:59 EDT

Yes, please backport this to RSE 3.2.x, where RDz always creates 2 private filters for every z/OS connection.  Backport to RSE 3.0.x is nice to have.

Comment 5 David McKnight

2011-09-30 10:07:05 EDT

Dave D, are you going to review this?

Comment 6 David McKnight

2011-09-30 11:31:40 EDT

I've committed the fix to the HEAD stream.

Comment 7 Martin Oberhuber

2011-09-30 15:01:43 EDT

Released into Mapfile for 3.4m3 -- rse.core bundle version was already updated.

Comment 8 Martin Oberhuber

2011-09-30 15:05:32 EDT

Is this maybe related to bug 233748 ("Deleting Filter Pool takes a long time and causes Property View to refresh a lot")

Comment 9 David McKnight

2011-09-30 16:24:56 EDT

(In reply to comment #8)
> Is this maybe related to bug 233748 ("Deleting Filter Pool takes a long time
> and causes Property View to refresh a lot")

I haven't tested the fix with bug 233748 but there's a good chance it's related.