Is it a good idea and safe to set mid server property mid.sm.discolog.max_object_size value to 500000 insted of default 1000

mkulish
Kilo Explorer

 

 

I am facing  an issue preventing service mapping of Citrix XenApp based application in the way described here.

 

https://docs.servicenow.com/bundle/madrid-it-operations-management/page/product/service-mapping/conc...

 

 At a stage of Controller discovery by pattern Delivery Controller  => Identification  step 6 {get application in xml format} obtains all configured applications by a PowerShell command. Customer has ~ 1000 entries. On the next step the output of the entries generate an error message

 

setAttribute(xml_output,The max object size reached the maximum limit of [1000]. To adjust this use the mid property mid.sm.discolog.max_object_size.)

 

Despite documentation indicates this property to be only for Horizontal Discovery Log objects it also effects behavior of Service Mapping in Discovery log.   https://docs.servicenow.com/bundle/madrid-servicenow-platform/page/product/mid-server/reference/r_MI...

 

Meanwhile the Debug Mode of the pattern doesn't give such error message. I think it should be taken into account in future releases.

 

 I have increased the default value 10 times to 10000 and it increased the output part shown in the service mapping log but it is not sufficient since one application entry in XenApp bring ~500 characters. I am not sure that it is safe to set the value to 500000. Please clarify how can we proceed to get the XenApp applications discovered by the pattern??

 

1 ACCEPTED SOLUTION

mamann
Mega Guru

I ran into this exact same issue in two different scenarios.

1) XenApp Mapping as you described

and

2) Discovering core routers with extremely larger SNMP Tables

 

I did change this property, but to 5000000 (5,000,000) and it fixed the issue.

As a note, This will cause the sensor processing in the ecc queue for these records to take a little longer (because the payload is much larger) and will use more memory anywhere the payload is stored (mid and instance), but I haven't noticed any adverse impact from it and we are running Discovery and Service Mapping quite a bit across hundreds of schedules.

View solution in original post

1 REPLY 1

mamann
Mega Guru

I ran into this exact same issue in two different scenarios.

1) XenApp Mapping as you described

and

2) Discovering core routers with extremely larger SNMP Tables

 

I did change this property, but to 5000000 (5,000,000) and it fixed the issue.

As a note, This will cause the sensor processing in the ecc queue for these records to take a little longer (because the payload is much larger) and will use more memory anywhere the payload is stored (mid and instance), but I haven't noticed any adverse impact from it and we are running Discovery and Service Mapping quite a bit across hundreds of schedules.