In TIBCO Data Virtualization, object creation (creating new folder, view, SQL script, packaged query etc.) may take longer than usual. This happens only when 'Copy privileges from parent folder' checkbox is selected.

Screenshot for reference:


Verify if the total number of Active Directory users and groups in TDV are higher than external group account users which explains that unwanted users have not been deleted from TDV side. Therefore, the create object function in TDV checks the user privilege for every user during object creation resulting in the delay.

To learn more about the create object functions, enable debug logging from Studio > Administration > Configuration > Server > Configuration > Debugging > Debug Output Enabled > Set it to 'true'. Examine the cs_server.log file which might show heavy use of getInheritedUserResourcePrivilege and fetchMemberCids. This would prove, the create object function checks user privileges for every user - approximately several hundreds - which would be the cause for delay.

Here is an example from cs_server log file: 

>>> 16 ms to create folder
DEBUG [jetty thread pool-237] 2019-03-25 21:08:45.304 -0700 ContainerImpl - [36392] CREATE name="test" type=1 subType=-10 parent="/users/composite/adminuser"
>>> start
DEBUG [jetty thread pool-237] 2019-03-25 21:08:45.320 -0700 RepositoryImpl - [36392] WRITE 1 dirty objects.
>>> setting privileges
DEBUG [jetty thread pool-236] 2019-03-25 21:08:45.460 -0700 WsapiServlet -
header.SOAPAction: "getResourcePrivileges"
>>> 30 ms hasEffectiveResourcePrivilege
DEBUG [jetty thread pool-236] 2019-03-25 21:08:45.460 -0700 AuthorizationManager - hasEffectiveResourcePrivilege(10100,adminuser,1)
DEBUG [jetty thread pool-236] 2019-03-25 21:08:45.492 -0700 AuthorizationManager - hasEffectiveResourcePrivilege(50102,SCRUBBEDUSER)
>>> 4 secs fetchMemberStates
DEBUG [jetty thread pool-236] 2019-03-25 21:08:45.507 -0700 JdbcRepository - fetchMemberStates(idCidsList={...
DEBUG [jetty thread pool-236] 2019-03-25 21:08:49.633 -0700 JdbcRepository - fetchMemberStates(idCidsList={{1,83350},{2,102081},{2348,83384}}, referenceCid=102204)
>>> 4 secs getInheritedUserResourcePrivilege
DEBUG [jetty thread pool-236] 2019-03-25 21:08:49.664 -0700 AuthorizationManager - getInheritedUserResourcePrivilege(50102,SCRUBBEDUSER)
DEBUG [jetty thread pool-238] 2019-03-25 21:08:53.695 -0700 AuthorizationManager - getInheritedUserResourcePrivilege(12830100,SCRUBBEDUSER)
>>> 2 secs fetchMemberCids
DEBUG [jetty thread pool-237] 2019-03-25 21:08:54.383 -0700 JdbcRepository - fetchMemberCids(domainId=50109, name=SCRUBBEDUSER, subtype=15)
DEBUG [jetty thread pool-237] 2019-03-25 21:08:56.446 -0700 JdbcRepository - fetchMemberCids(domainId=50109, name=SCRUBBEDUSER, subtype=15)
>>> wrapup - 11 secs total
DEBUG [jetty thread pool-238] 2019-03-25 21:08:56.836 -0700 WResourceImpl - Resource Updates (109 ms):
DEBUG [jetty thread pool-238] 2019-03-25 21:08:56.836 -0700 WResourceImpl -   Changed:
DEBUG [jetty thread pool-238] 2019-03-25 21:08:56.836 -0700 WResourceImpl -     /users/composite/adminuser/test (-1/12830100) true
DEBUG [jetty thread pool-238] 2019-03-25 21:08:56.836 -0700 WResourceImpl -   Added:
DEBUG [jetty thread pool-238] 2019-03-25 21:08:56.836 -0700 WResourceImpl -   Moved:
DEBUG [jetty thread pool-238] 2019-03-25 21:08:56.836 -0700 WResourceImpl -   Deleted:
DEBUG [jetty thread pool-238] 2019-03-25 21:08:56.836 -0700 WResourceImpl - ======================

To avoid such behavior, perform any of the following step:

(1)  Manually remove unwanted users from TDV side from the Web Manager.
Note: Removing a user should be a conscious decision by admin since users no longer exist in LDAP account so they won't be able to login and their respective user folders will be removed. Therefore, retain the folder contents by changing the owner before removing the user. For additional information, refer to chapter 'Remove LDAP users from TDV' from the AdministrationGuide (Pg. 214):

(2)  Execute the Admin API to remove the user. The API can be found in TDV Studio, under Composite Data Services > Web Services > system > admin > user > operations > destroyUser. The Info tab provides details on API usage.
Note: Change the user's folder resource owner before executing the API. This would still be a manual process to find the users that no longer exist in AD.

(3)  Execute the SyncDomain procedure which synchronizes the local external domain with the specified external domain server. This procedure can be found in TDV Studio, under Modeler > localhost > lib > users > SyncDomain.
Note: This might delete groups and users in TDV that actually existed in AD. Occasionally, when retrieving group information from AD, the AD server fails to return the list of groups and it does not return an error either so TDV deletes all groups and their users for the domain from TDV side. Use this procedure, but with caution. Before performing this step, kindly take a full server backup which includes users and their folders.

(4)  Delete all the AD users from TDV side and let the user creation happen for the active users once they login to TDV for the first time. From Web Manager, navigate to Domain Management > select the external groups > users      
Note: Delete few active user's and verify they can login to TDV. Perform this step if user's do not create any database objects in TDV and only access them using client connections.  

Screenshot for reference:

Option(4) is the best practice to follow in such scenario.  

How to avoid delay in object creation in TIBCO Data Virtualization when 'Copy privileges from parent folder' checkbox is selected?

Administration Guide: 
https://docs.tibco.com/pub/tdv/8.0.0/doc/pdf/TIB_tdv_8.0.0_AdministrationGuide.pdf?id=3