OOM in MID over file attachment api

[guykl]

i am using a mid server script that pulls a file and attaches it to another object via the attachment api. 

But when  i ran it i get OOM on heap space in the mid server. The file is around 1.5GB.

The wrapper.java.memory is 4096 = 4GB, and also the instance is set to 4GB, so idk what i should do next.

also the file is a zip that i get from ServiceNow for the Content library for SAM, so i can't just split it or something

[Sreeram Nair]

If the zip already exists as an attachment in your ServiceNow instance (common with SAM content downloads), don’t download/re-upload. Just copy (or relate) the attachment inside the instance.

If you’re fetching via REST, use “save response as attachment” (streaming) — not “getBody()”
When you do a REST call from ServiceNow, use RESTMessageV2.saveResponseBodyAsAttachment(...) so the platform writes the response directly to an attachment, instead of loading it into script memory.

That pattern is specifically meant to avoid huge in-memory payload handling.

If you truly can’t avoid moving the file through the MID, then the current sizing is the core issue:

Don’t set heap equal to machine RAM. Give the box at least 8–16 GB RAM.

Then raise wrapper.java.maxmemory accordingly (and confirm you’re on a 64-bit JVM, since 32-bit JVMs have much lower practical heap ceilings).