MID Server queue.stats sensor business rule "MID - Process XMLStats" doesn't check for large result payload.txt attachments - Known Error

MID Server queue.stats sensor business rule "MID - Process XMLStats" doesn't check for large result payload.txt attachments Description MID Server queue.stats sensor business rule "MID - Process XMLStats" doesn't check for payload.txt attachments for large results and throws errors in syslog. The metrics and threads records will not get updated in the MID Server's related lists and MID Server Dashboard.

In some situations, such as a known error causing leaking/orphaned/stuck threads, the list of running threads in the MID Server can be large enough for the result to be more than the SOAP Table API property limit (glide.soapprocessor.large_field_patch_max), and move the payload value into payload.txt attachment, and put as the field value. Sensor business rule "MID - Process XMLStats" assumes the result will be in the actual payload field., and does not check for an attachment, as many other sensors do.

Steps to Reproduce

Have a very large number of threads currently running in a MID Server e.g. 4815 seen in one example (usually only possible when a known leaking thread problem is happening) Wait up to 10 minutes for a queue.stats/XMLStats input from the MID Server Note that threads and the various metrics records are not updated/added by the sensor. Check the syslog, for the following warnings: org.mozilla.javascript.EcmaError: Cannot convert null to an object. Caused by error in sys_script.5806ceff0a0a0b3a00085c20c438ec1c.script at line 26 23: 24: var threadsNode = XMLUtil.selectSingleNode(root, "//threads"); 25: var threadsList = XMLUtil.selectNodes(threadsNode, "//thread"); ==> 26: for (var i = 0; i 27: var thread = threadsList.item(i); 28: var tName = XMLUtil.getAllText(thread); 29: var tDaemon = thread.getAttribute("daemon"); org.mozilla.javascript.EcmaError: Cannot convert null to an object. Caused by error in sys_script.5806ceff0a0a0b3a00085c20c438ec1c.script at line 84 81: } 82: } 83: ==> 84: parseStats(); 85: current.state = 'processed'; 86: current.processed = gs.nowDateTime(); 87: current.update(); Workaround This problem is currently under review. You can contact ServiceNow Technical Support or subscribe to this Known Error article by clicking the Subscribe button at the top right of this article to be notified when more information becomes available.

As a workaround, assuming the large payload is due to orphaned/hung/leaked/stuck threads, that thread problem will need resolving. The payload will then be under the limit for moving to attachments.

e.g. If you see hundreds of DefaultUDPTransportMapping threads, then it may be PRB1495917 (or PRB1414364, PRB1426331, PRB1432247).