I am running some tests with sending larger data to a SOAP webservice.
70MB worked, was slow but no error.
Then I increased it to 700MB and after a longer time my prowin32 client crashed.
That's the call, both datasets have only one TempTable.
run Operation_1 in hWebService_TestWCFPublishSoap(input DATASET ExchangeRates, output DATASET RootDset).
=====================================================
PROGRESS stack trace as of Wed Mar 22 13:29:38 2017
=====================================================
Progress OpenEdge Release 11.5 build 1190 SP01 on WINNT
Startup parameters:
-pf C:\Progressx86\OpenEdge\startup.pf,-cpinternal ISO8859-1,-cpstream ISO8859-1,-cpcoll Basic,-cpcase Basic,-d mdy,-numsep 44,-numdec 46,(end .pf),-s 200,-mmax 65534,-db winsure.db,-H localhost,-S 12001,-U winsure,-P ******,-debugalert,-rereadnolock,-inp 16000,-tok 4000,-nosplash,-T C:\OpenEdgex86\WRK,-inp 32000,-noinactiveidx,-ininame c:\winsure\InterHannover.lok\cwinsure.ini,-p C:\Progressx86\OpenEdge\oeide\eclipse\plugins\com.openedge.pdt.debug.core_11.5.1.00\abl\_debuglauncher.p
Exception code: C0000005 ACCESS_VIOLATION
Fault address: 73BB1F18 01:00000F18 C:\Windows\system32\MSVCR100.dll
Registers:
EAX:00000031
EBX:076ADA14
ECX:00000008
EDX:00000000
ESI:076ADA14
EDI:2617BFF5
CS:EIP:0023:73BB1F18
SS:ESP:002B:0045EEB0 EBP:0045EEB8
DS:002B ES:002B FS:0053 GS:002B
Flags:00210246
Debugging dll: C:\Progressx86\OpenEdge\bin\DBGHELP.DLL
Symbol Path:
C:\Progressx86\OpenEdge\bin;C:\Progressx86\OpenEdge\pdbfiles
Call Stack:
Address Frame
73BB1F18 0045EEB8 memcpy+98
006D9C3D 0045EEFC proSAXInsertAttribute+C1D
06F75895 0045EF28 xercesc_3_1::XMLFormatter::formatBuf+CA
06F75C26 0045EF4C xercesc_3_1::XMLFormatter::specialFormat+57
06F75817 0045EF7C xercesc_3_1::XMLFormatter::formatBuf+4C
06F759FA 0045EF98 xercesc_3_1::XMLFormatter::operator<<+21
006DA1C9 0045EFA8 proMemioInit+509
006D741C 0045EFBC proSAXWriterExecute+18C
** ABL Stack Trace **
--> C:\winsure\shd.lok\InterHannover\Server\resqexport.p at line -1 (C:\winsure\shd.lok\InterHannover\Server\resqexport.r)
adecomm/_runcode.p at line 665 (adecomm/_runcode.r)
C:\Progressx86\OpenEdge\oeide\eclipse\plugins\com.openedge.pdt.debug.core_11.5.1.00\abl\_debuglauncher.p at line 100 (C:\Progressx86\OpenEdge\oeide\eclipse\plugins\com.openedge.pdt.debug.core_11.5.1.00\abl\_debuglauncher.p)
** Persistent procedures/Classes **
** PROPATH **
....
What do I need to increase that I can theoretically send messages up to the IIS/Biztalk limit (2GB)?
(Your title has the typo 10.5.1, as your protrace shows "11.5 build 1190 SP01".)
Sorry Robin, I was writing this up as you replied. It took a bit of research.
The memory stack that you have provided aligns perfectly with a bug that was found in 11.5.0 and fixed in 11.6.0.0.
Both performance issue and the crash (only happened on Win32) were resolved. The performance was resolved by changing from 16 KB linear memory growth for large buffers to a declining exponential factor growth. The crash was resolved by handling the out of memory condition better.
Due to the scope of the fix, it was deemed as not suitable to go into a hotfix.
Switching to 64 bit and sticking with 11.5 you will still see the performance issue and then an out of memory error—but no crash.
If you can, upgrade to 11.6.
However, it is likely the case that even after upgrading you will still not get your code to run as you are going to still be running out of memory unless the 64 bit machine has better resources—like more memory.
If you talk to tech support the Issue in question is PSC00337748.
If you are "playing with it" then I can't help you. But if you are planning to really use that, I can tell you that anything above 1Mb is a bad idea when talking about web transfer.
You should "chunk it" and transfer it by pieces. That means you will better off having 2 services, 1 for the chunked transfer, and one to do the job, after the transfer (you can do both with just 1, but having 2 is simpler and more flexible).
I've been bitten (several times, I must say) by "large packets", even on internal LAN environments. The larger the packet, the longer the list of probable failure points along the way.
Another important point is that if the service fails, and you have to retry, you will need to transfer the whole packet again, when using chunks, you will only need to re-transfer the failed chunk, and you can try to process what already transfered as many times as you want, without having to re-transfer anything.
My main idea is that when I don't chunk it, I can say from the client: I delivered, I am great, now I am out of the game.
Chunking creates big pains, transaction, saving chunks where? ...
O.k., in case of an abort I need to restart at the last chunk again but I do have still the transaction problem, especially in this case.
Yes, I am playing to identify potentially problem as I did now.
64bit is on the way, I am waiting for my new laptop.
The AVM should never crash. Please log a bug through Tech Support.
(Your title has the typo 10.5.1, as your protrace shows "11.5 build 1190 SP01".)
Sorry Robin, I was writing this up as you replied. It took a bit of research.
The memory stack that you have provided aligns perfectly with a bug that was found in 11.5.0 and fixed in 11.6.0.0.
Both performance issue and the crash (only happened on Win32) were resolved. The performance was resolved by changing from 16 KB linear memory growth for large buffers to a declining exponential factor growth. The crash was resolved by handling the out of memory condition better.
Due to the scope of the fix, it was deemed as not suitable to go into a hotfix.
Switching to 64 bit and sticking with 11.5 you will still see the performance issue and then an out of memory error—but no crash.
If you can, upgrade to 11.6.
However, it is likely the case that even after upgrading you will still not get your code to run as you are going to still be running out of memory unless the 64 bit machine has better resources—like more memory.
If you talk to tech support the Issue in question is PSC00337748.
Hi Alex,
thank you for the very detailed information.
I will try 11.6 as soon as possible, meanwhile we have 11.6 64bit on production, only my dev laptop is still running with 11.5.1 32bit.
This issue is also documented in the following KBase article: