If system property glide.soapprocessor.large_field_patch_max is set to 2147483648 or greater (2.14GB), the integer overflows, resulting in every field value on the record being replaced by "<see_attachment/>" and each moved into an attachment.

As all ECC Queue inputs are created via SOAP, this break the ECC Queue, and so MID Servers can no longer communicate with the instance, and go Down.

System property "glide.soapprocessor.large_field_patch_max" is described as "Maximum number of bytes per field in the incoming SOAP action. If the incoming value exceeds this size, it will be converted into an attachment to the record."
Default: 512000 (512KB)

No maximum value or range is documented. The overflow is not checked.

These steps use a MID Server to create the inbound SOAP, which is its normal way of creating an ECC Queue input. A customer MID Server outage did happen this way. This should also apply to any inbound SOAP request.

1. Install a MID Server
2. Set System property "glide.soapprocessor.large_field_patch_max" to 2147483648
3. Send the MID Server a job, perhaps Grab Logs form the MID Server form
4. Check the ECC Queue. All inputs from now on will have all field values replaced by <see_attachment/> and each filed will have an attachment in the name of the field.

Set the property to 2147483647, and it will start to work again.

This is expected behavior and by design in all currently supported releases.

Setting a value of >2147483648 is over 2.1GB, and simply wrong, even if it didn't cause this problem. The platform, user interface and web browsers simply cannot handle that much data in a field, so customers should correct this to a lower value to resolve the issue. We recommend reverting to the default 512000 value (512KB).