Using Process Private Global:

ClassMethod setLayout(layout) As %Status
{
	MERGE ^||layout = layout

	Set node="^||layout"
	For  {
		Set node=$query(@node) Q:node=""
		Write node,"=",@node,!
	}
	Quit $$$OK
}

Using local variable array:

ClassMethod arrayQuery(myArrayLocalName) [ PublicList = myArrayLocalName ]
{
	Set node="myArrayLocalName"
	For  {
		Set node=$query(@node) Q:node=""
		Write node,"=",@node,!
	}
}

Note: the idea of using Process Private Global was INSTEAD of local variable array all around, not merging etc.

Another option, in your BO add:

Property LocalInterface As %String(MAXLEN = 255);
Parameter SETTINGS = "LocalInterface:Connection:selector?context={Ens.ContextSearch/TCPLocalInterfaces}";

Then before calling the service (..Adaper.Invoke*()) add this:

	If 'IsObject(..Adapter.%Client.HttpRequest) {
		Set ..Adapter.%Client.HttpRequest=##class(%Net.HttpRequest).%New()
	}
	Set ..Adapter.%Client.HttpRequest.LocalInterface=$ZStrip($P(..LocalInterface,"("),"*W")
	

Edit to add: Why are you extending EnsLib.SOAP.GenericOperation?

For a SOAP BO using EnsLib.SOAP.OutboundAdapter the class signature is supposed to be:

Class osuwmc.Nutrition.OSU.CBOARDNetMenuOperation.CBORDHL7Port Extends Ens.BusinessOperation
 

That won't work, you are just setting a %Net.HttpRequest object in a (private) variable called HttpRequest that is destroyed when the method ends.

You need to set/change the %Net.HttpRequest instance contained in the ..%Client property of the adapted AFTER the web service client class is set/instantiated in ..%Client.

Did you had a chance to test the modified adapter I've posted? Maybe tomorrow I'll have time to test it.

You can extend EnsLib.SOAP.OutboundAdapter and add support for LocalInterface and use the "new" adapter in your BO.

With "inspiration" 😁 from EnsLib.HTTP.OutboundAdapter, something like:

Class Community.adapter.SoapOutbound Extends EnsLib.SOAP.OutboundAdapter
{

/// In a multi-homed system, specify which network interface the TCP connection should go through.  An empty value means to use any interface. <br/>
/// To be able to bind to IPv6 interfaces you may need to enable IPv6 in your instance.  This is done in the System Management Portal under 
/// System Administration > Configuration > Additional Settings > Startup, by editing the IPv6 setting.
Property LocalInterface As %String(MAXLEN = 250);
Parameter SETTINGS = "LocalInterface:Connection:selector?context={Ens.ContextSearch/TCPLocalInterfaces}";
Method OnInit() As %Status
{
	Set ..%Client.HttpRequest=##class(%Net.HttpRequest).%New()
	Set ..%Client.HttpRequest.LocalInterface=$ZStrip($P(..LocalInterface,"("),"*W")
	Return ##super()
}

}

I did not tested it, try it and let us know.

Nete, if for any reason you reinstantiate ..%Client.HttpRequest, then you need to set the LocalInterface  property.

Having LocalInterface support in EnsLib.SOAP.OutboundAdapter "out of the box" can be worth an entry in the ideas portal.

$query argument can be a global or a public variable, so when using local variable array change the method signature:

ClassMethod test(array) [ public= array ]

Or use a temp global or, even better, a Process Private Global instead.

In the...good old days, we used to do that in one line 😂

s node="array" f  s node=$q(@node) q:node=""  w node,"=",@node,!

array(1)=1
array(1,1)=1,1
array(1,1,1)=1,1,1
array(1,1,1,1)=1,1,1,1
array(1,1,2)=1,1,2
array(1,1,3)=1,1,3
array(2)=2
array(2,1)=2,1
array(2,1,1)=2,1,1

If you want/need your code to handle ANY situation (JSON size), then you should use the first option.

Let's try with the second option:

USER>Set Body={}.%FromJSONFile("c:\temp\BigSample.json")
 
USER>Set Request = ##class(%Net.HttpRequest).%New()
 
USER>Set Request.Server = "server"
 
USER>Set Request.Location = "location"
 
USER>Set Request.ContentType = "application/json"
 
USER>Do Request.EntityBody.Write(Body.%ToJSON())
DO Request.EntityBody.Write(Body.%ToJSON())
^
<STRINGSTACK>
USER>

As you see, it does not work. Now the first option:

SER>Set Body={}.%FromJSONFile("c:\temp\BigSample.json")
 
USER>Set Request = ##class(%Net.HttpRequest).%New()
 
USER>Set Request.Server = "server"
 
USER>Set Request.Location = "location"
 
USER>Set Request.ContentType = "application/json"
 
USER>Do Body.%ToJSON(Request.EntityBody)
 
USER>Write Request.EntityBody.Size
18378462
USER>Write ##class(%File).%New("c:\temp\BigSample.json").Size
50273869
USER>

Curiosity: the difference between the original json file size and stream loaded into Request.EntityBody stream is due to the fact that the file is formatted with indents while the json exported stream is "compact" (minified) with no indents and new lines.

This is new info, you did not mention this in your original question.

Can you provide some context on your implementation?

Would you mind to share the code you are using to save "data inside response.Data"?

What class is "response"?

From the example in the first post it seems the stream is not a property of an Ens.Message, that's why is not purged.

You explicitly saved the stream using CopyFromAndSave(), so it will persist (on disk) until it's deleted.

It's like saving a persistent class, it persist even when the code has finished executing. Fortunately! ☺

What's the point of saving a stream that you don't want to persist?

But...are you using a Business Operation with EnsLib.SOAP.OutboundAdapter?

What namespace are you logged when you try to create that routine?

Maybe in your namespace the %Test (or %Test*, or...) is mapped to a read only database?

Otherwise you think you are authenticated as superuser but in fact you are not.

In your generated (from wsdl) SOAP client class change the LOCATION class parameter with correct url including port number.

Another option is to set the Location property in your code when you use the client class, somthing like:

Set wsClient=##class(your.generated.SoapClient).%New()
Set wsClient.Location="https://path.to.server:NNNN/path.to.service"
Set client.SSLConfiguration ="SSLConfig"

It looks like there is some disk I/O difference between the two systems.

How does the two systems storage (disk, controller etc.) compares?

Are the 2 systems equally configured in terms available RAM and of global buffers?

Is the shared memory using large pages? (check messages.log during startup)

I'd monitor and compare disk usage and I/O while running.

I had a similar issues with IRIS 2021.2.

In one case a class with an object reference calculated property failed to compile.
The workaround was to add %JSONINCLUDE = "OUTPUTONLY" to the property.

The second case was a class that contains a property (not calculated) that is an array of %Stream.GlobalBinary (that was not supported) and despite I added %JSONINCLUDE = "NONE" the class did not compile.
For this I got a quick fix modifying a library class.

My suggestion is first to to reproduce the issue with a VERY SIMPLE test case and test it using latest IRIS version 2025.1 and, whatever the test result is, report it to WRC including the result of your test using the latest IRIS version.

05/16/25-15:43:17:397 (11856) 2 Failed to allocate 882MB shared memory: 411MB global buffers, 300MB routine buffers
05/16/25-15:43:17:398 (11856) 2 Unable to allocate shared memory minimum of 128MB
 

It must be a very small system!

Maybe you are sending the HTTP request using an incorrect Content-Type HTTP header?

Check what Content-Type HTTP header the receiving end is expecting.