Community
Participate
Working Groups
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.
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.
Dave D, could you please review the patch?
Masao, does this need to be backported to RSE 3.2.x or RSE 3.0.x?
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.
Dave D, are you going to review this?
I've committed the fix to the HEAD stream.
Released into Mapfile for 3.4m3 -- rse.core bundle version was already updated.
Is this maybe related to bug 233748 ("Deleting Filter Pool takes a long time and causes Property View to refresh a lot")
(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.
