When running vCenter discovery, some of the VMWarevCenterESXHostsStorageProbe probes can not be processed with the error message: Payload attachment exceeds the limit of 5242880 bytes set by system property com.glide.attachment.max_get_size
It is possible to increase the parameter size, however this is not a desired solution as explained in below documentation:
A better structural fix is needed.

Steps to Reproduce

  1. Get an environment with vCenter running on it.
    2. Run discovery on the vCenter environment.
    3. Manipulate one of the VMWarevCenterESXHostsStorageProbe input payload records to a bigger size than 5MB.
    4. Run the sensor on this probe again, and you should get the error message: Payload attachment exceeds the limit of 5242880 bytes set by system property com.glide.attachment.max_get_size.


After carefully considering the severity and frequency of this problem, and risk of attempting a fix, it has been decided to not address this issue in any current or future releases. We do not make these decisions lightly, and we apologise for any inconvenience.

Instead, the possible solution for this would be:

  1. Go to the "Probes" under "Discovery Definition".
  2. Search for the probe name that is causing the payload size issue(s).
  3. In the below tabs - "Probe Parameters" section, add the parameter name whose name is "page_size"
  4. Go to MID Server Script Include("ecc_agent_script_include") table
  5. Open the script include whose name is according to the probe name (== SCREENSHOT -1.png ==)
  6. Search in the script with text as "parseInt(probe.getParameter('page_size'))" then you'll fine below code:
    parseInt(probe.getParameter('page_size')) || <<SOME NUMBER>>
  7. Copy the number which you saw in step 6 and now open the probe parameter created in step 3
  8. Put the lesser number or half of it in the value of the probe parameter. (== SCREENSHOT -3.png ==)

This "page_size" parameter is used to determine how many CIs data the logic should look into for one request (1 ECC Queue Payload). By default, the value is "5". If there is no such parameter, the logic will prepare payload containing the data about 5 CIs at max.

There will not be much performance impact but the discovery might take some more time because we get 1 by 1 CI for each ECC queue instead of getting 5 all at once in 1 ECC Queue. 


Related Problem: PRB1396319

Seen In

Geneva Patch 4
Geneva Patch 5
Geneva Patch 6
Helsinki Patch 3 Hot Fix 7
SR - IRM - Audit Management - New York 2019 Q3
SR - IRM - Audit Management PA Content - Madrid 2019 Q1
SR - IRM - GRC Profiles - Madrid 2019 Q2
SR - IRM - GRC Workbench - New York 2019 Q3
SR - IRM - PA Premium Integration - New York 2019 Q3
SR - IRM - Policy and Compliance - Madrid 2019 Q2
SR - IRM - Policy and Compliance PA Content - Madrid 2019 Q1
SR - IRM - Risk Management - New York 2019 Q3
SR - IRM - SIG Assessment Legacy - Madrid 2019 Q1
SR - IRM - SIG Questionnaire - New York 2019 Q3
SR - IRM - Vendor Risk Management - Madrid 2019 Q1

Intended Fix Version


Safe Harbor Statement

This "Intended Fix Version" information is meant to outline ServiceNow's general product direction and should not be relied upon in making a purchasing decision. The information provided here is for information purposes only and may not be incorporated into any contract. It is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for our products remains at ServiceNow's sole discretion.

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2020-10-24 19:37:49
SCREENSHOT -1.png[View]SCREENSHOT -3.png[View]