I’m using the latest locally build version, but no relevant changes have been made in this area since April, I believe. That said, jic, maybe test with 1593?
I downloaded 1593, and upgraded the project. But it didn’t help, I can still reproduce it everytime. (I have experienced this on multiple machines, and I can reproduce this consistently. So to my mind it probably has todo with the rem objects version?)
You can also try increasing the file size to more then 100mb in the GetBigBinaryFile?
Here is a zip with the .exe that I have compiled thats doing this (Altho ahm, please don’t execute .exe from strangers on the internet 
I’m sending it on the off chance you have a way to run it safely.):
net7.0-windows.zip (1.4 MB)
Another thing that might be good to test, is to put a breakpoint in one of these functions:
at RemObjects.SDK.Connection.IntBeginWrite(Byte[], Int32, Int32, System.AsyncCallback, System.Object)
at RemObjects.SDK.Connection.BeginWrite(Byte[], Int32, Int32, System.AsyncCallback, System.Object)
at RemObjects.SDK.Server.AsyncHttpServerWorker.ResponseBodyCallback(System.IAsyncResult)
That’s what I was using to test if my scenario was the one I was looking for. When the call is causing that function to be used (The recursion its involved in anyways). Then the failure has to happen given a sufficiently large transfer, given the code that I’ve seen anyways.
If when you run it, they aren’t being called. That means that something is different in your scenario that is causing the data to be transferred differently.
No problem with 500MB either – though it takes longer than i’d have expected.
Calling GetBigBinaryFile service method…
GetBigBinaryFile service method called! Size is 524288000
I cant easily, no. I’ve asked my colleage to test your testcase on his system well…
FTR, here’s the final version of your testcase im running, after some tweaks I had to mako to get it to build.
ReportingService 2.bugreport.zip (68.8 KB)
I get the stackoverflow error, with your exact setup, with no other changes.
Aside from testing one of the released versions (as opposed to the locally built ones) I don’t really have good ideas.
The location of the bug I think is known tho, but I guess its a question of why is it not being triggered for you. (I still recommend putting a breakpoint, to make sure that for you its not simply using a different part of the code todo the transfer).
at RemObjects.SDK.Connection.IntBeginWrite(Byte[], Int32, Int32, System.AsyncCallback, System.Object)
at RemObjects.SDK.Connection.BeginWrite(Byte[], Int32, Int32, System.AsyncCallback, System.Object)
at RemObjects.SDK.Server.AsyncHttpServerWorker.ResponseBodyCallback(System.IAsyncResult)
Reproduced. I had an SO once (maybe it’s a luck thing, depending on how big the stack is), but in allotter runs, it succeeds but IntBeginWrite is called some 25,000 times, recursively.
This is bad, but it might just be how the channel designed right now, and mot sure if it’s an easy fix. For now, as workaround, i’d say either use the SuperHttpClientChannel,or dont send this much data in one call (a good idea in general) 
But I’ll see what I can do to rework this.
Oddly, on my very next try. SO after “only” 3000 lines on the stack. It seems that .NET Core has widely varying stack depths…
Logged as bugs://D19479.
I do have a potential fix; I’ll send you a new build as soon as one finishes on CI.
Great to hear!
Yea I was wondering if it could be a varying stack size, only thing it could be if its being sent the same way. Or maybe its doing some compression, and random bits is not the best test case for reproducibility x)
Its true that its not a good idea to send such large files this way 
Its between two docker containers on the same machine, so this thread is the answer to the thought “What can possibly go wrong”.
New build is in the personal downloads for the account that hold the licenses. Please let,e know (a) if it solves the issue for you and (b) if you see anybotgher negative side effects.
That could also it, yes!
.
Yeah, within the same docker setup, this SHOULD be fine to do. I just usually recommend against sending more than, say 1-2MB at a time from real “client” applications across the “public” (and possibly unstable, connection-wise) internet…