Server crashes during large package installation through SOAP

Hi Bartosz, 

It could be anyone of the below. whenever requesting troubleshooting, please state version.

First cause: Apache CampaignLimitRequest

In ACC build 8797 (released 17.4.1), Adobe introduced a content length limit for the Apache and IIS front-end layer. This defaults to 50 MB but in older configurations, or where CampaignLimitRequest was set conservatively, it can be much lower. Adobe However the more relevant limit for SOAP-delivered packages is a separate one that sits before even Apache: the Campaign web process itself imposes its own request body ceiling. When a SOAP call to xtk:builder#InstallPackage or equivalent carries a 1.2 MB XML body, the web@default process can exhaust its allocated memory while buffering and DOM-parsing the payload, triggering the segfault that produces iRc=-53.

Second cause: JavaScript interpreter memory ceiling

The JavaScript interpreter bundled with Campaign has an upper limit on memory it can use. The default allocation is 64 MB, and when processing large data volumes this needs to be raised. Adobe Package installation involves significant JS-side processing — schema compilation, entity resolution, dependency resolution across custom schemas — and a 1.2 MB XML tree with multiple custom schema definitions will expand considerably in memory during that phase. If javascript maxMB in serverConf.xml is still at the 64 MB default, this alone can kill the web process.

Third cause: Tomcat connector maxPostSize

Adobe Campaign uses an embedded Apache Tomcat servlet to process HTTP/HTTPS requests between the application and any external interface, including SOAP calls. Adobe Tomcat's HTTP connector has a maxPostSize attribute on the <Connector> element in server.xml (located in /tomcat-X/conf/). The default in older Tomcat versions is 2 MB, and in some builds it is set lower. If the serialised SOAP envelope wrapping the 1.2 MB XML pushes the total POST body above that threshold, Tomcat silently rejects or truncates it in a way that causes the web process to crash rather than return a clean 413.

Fourth cause: front-end Apache LimitRequestBody

If Apache sits in front of Tomcat, it has its own LimitRequestBody directive. The CampaignLimitRequest value in httpd.conf controls this, and changing it is the documented resolution for 413-class errors during large uploads. Adobe Even if the SOAP call does not hit this limit cleanly, a misconfigured or absent directive can cause the connection to be aborted mid-stream, again producing a crash in web@default rather than a graceful error.

What to check and fix, in order

In serverConf.xml, find the <javaScript> node and raise maxMB from its default. Increasing it from 64 MB to 512 MB is considered almost mandatory for custom and complex processing on large volumes. Adobe Experience League This is the single most common fix for web@default crashes on large package installs.

In /tomcat-X/conf/server.xml, locate the <Connector port="8080" element and add or raise maxPostSize to something comfortably above 1.2 MB — a value like 10485760 (10 MB) is reasonable.

In httpd.conf (if Apache is the front-end), set or raise CampaignLimitRequest to at least 10485760.

After any serverConf.xml change, run nlserver config -reload and restart the web process. After server.xml or httpd.conf changes, a full service restart is required.