UD issues related to client computers working from home

Has anyone noticed any issues with discovery related to so many client computers are working from home?

My discovery pattern includes client computers (laptop / desktop). I use Inventory Discovery by Scanner and Host Connection by Shell with UD Agent as the shell. My IP ranges include the Cisco VPN pool as client network type. This setup is working well and I'm receiving scan files from the VPN network.

My problem is with IP addresses and interfaces causing reconciliation and performance issues on the UCMDB server. All the Cisco VPN adapters share the same MAC address. There are many computers associated to the subnet. Yesterday I was no longer able to open the DFM module in the admin UI because of the following error for one of the jobs trigger queries:

Caused by: com.mercury.topaz.cmdb.shared.base.CmdbException: [ErrorCode [1004] Query result exceeded size limit. Please refine your query. Cause: "Join" relationship calculation. Size limit: {0}{20000000}] appilog.framework.shared.manage.impl.MamResponseException: [ErrorCode [1004] Query result exceeded size limit. Please refine your query. Cause: "Join" relationship calculation. Size limit: {0}{20000000}] CMDB Operation Internal Error: class com.mercury.topaz.cmdb.server.manage.dal.CmdbDalException : Joinf Results exceed maximum value [max results value is: 20000000] : operation Model Query: Get Join Links of objects : source element condition [class name:ip_address is_derived:true properties:(NOT(ip_probename IS_NULL '' isProperty:false))AND((ip_isbroadcast EQUEL 'false' isProperty:false)OR(ip_isbroadcast IS_NULL '' isProperty:false))], destination element condition [class name:shell is_derived:true], pattern join link [[com.mercury.topaz.cmdb.shared.tql.definition.graph.impl.JoinfPropertyConditionImpl@ec9cce21]] at com.mercury.topaz.cmdb.shared.manage.operation.impl.AbstractCommonOperation.execute(AbstractCommonOperation.java:160) at com.mercury.topaz.cmdb.server.manage.rpm.RequestProcessor.doProcessRequest(RequestProcessor.java:238) at com.mercury.topaz.cmdb.server.manage.rpm.RequestProcessor.doProcessRequestWithQueueLimitation(RequestProcessor.java:247) at com.mercury.topaz.cmdb.server.manage.rpm.RequestProcessor.processRequest(RequestProcessor.java:201) ... 85 more Caused by: appilog.framework.shared.manage.impl.MamResponseException: [ErrorCode [1004] Query result exceeded size limit.

With so many people in the world now working from home I wanted to see if other people are also having issues with their discovery.


  • Hi  

    my suggestion is for you to simplify the trigger query of host connection by shell. It is unnecessary complex by default - it has two parts:

    1. Obtaining IPaddresses which have Shells attached  (by 2Joins of Application IP or ARP MAC address) 

    2. Obtaining IPAddresses without Node and Shell.


    Instead of that you can just replace everything with only "IPAddress" which have IpProbe Name defined.

    Of course, you can always raise the join limits in JMX. 


    Petko Popadiyski

    Freelance Microfocus CMS UCMDB Consulting

  •   I understand your suggestion of removing joins from trigger TQLs like ip_with_shell_or_without_host and using a simple trigger TQL like ip. Host connection by Shell job needs a shell so just trying everything with IP Address would just increase the number of connections the probe server needs to make without regard if there is a shell associated with the IP Address.

    I have increased memory of UCMDB server from 24Gb to 48Gb. I have also increased the fuse dal.joinf.max.result.size from 20M to 30M. Also, I have excluded the Cisco VPN adapter MAC address from arp mac in the ip_address identification rule for short lease time devices:

    <match> <verification-criteria> <verification-criterion> <attribute-condition attributeName="ip_lease_time" includeNullValue="false" conditionType="approveAndContradict"> <include-only> <value>1</value> </include-only> </attribute-condition> <attribute-condition attributeName="arp_mac" includeNullValue="false" conditionType="approveAndContradict"> <exclude> <value>00059A3C7A00</value> </exclude> </attribute-condition> </verification-criterion> </verification-criteria> <validation-criteria>



  • John,

    host connection by shell does not need shell to run. The outcome of the job is shell CI. The job runs based on the result from ICMP job.

    My suggestion is to leave only IP CI Type in the trigger querty, removing both the joins and the shells. You will end up with the same amount of triggers as now, since currently the query contains IPs without shell Cis plus IP with shell CIs. You will just simplify everything. I have no idea why the trigger query is so complex now. There is 0 reasons I can think of.



  • Just a crazy thought but do you have any kind of interfaces which start with veth ? I'm talking about the name of the interfaces.