[Mono-bugs] [Bug 71001][Cri] Changed - xsp.exe virtual size grows without bound -- large messages

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by gonzalo at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=71001

--- shadow/71001	2005-06-07 20:24:38.000000000 -0400
+++ shadow/71001.tmp.21774	2005-06-07 21:46:08.000000000 -0400
@@ -1,13 +1,13 @@
 Bug#: 71001
 Product: Mono: Runtime
 Version: unspecified
 OS: SLES 9
 OS Details: AMD-64
-Status: REOPENED   
-Resolution: 
+Status: RESOLVED   
+Resolution: WONTFIX
 Severity: Unknown
 Priority: Critical
 Component: misc
 AssignedTo: mono-bugs at ximian.com                            
 ReportedBy: jrodman at ximian-bugzilla.spamportal.net               
 QAContact: mono-bugs at ximian.com
@@ -145,6 +145,31 @@
 
 The 1.7GB of memory usage aside, our appliance stays up for long
 periods of time and the other services that run on the appliance need
 all the memory they can get.
 
 Thanks in advance, please let me know if there is anything else I can do!
+
+------- Additional Comments From gonzalo at ximian.com  2005-06-07 21:46 -------
+Uploading a large file without splitting it is a bad idea.
+
+The whole 46MB chunk is kept in memory and copied afterwards to do
+whatever you do (+filters, +...). We need to keep it like that to
+behave as MS. Btw, you should realize that uploading big files like
+that is a bad idea because you had to increase the request size limit
+in machine.config/web.config.
+
+Those *big* buffers with some help of the garbage collector are the
+cause of the 'memory leak' you're seeing.
+
+Two possible solutions are redirecting the POST at apache level
+(rewrite?) or if your customer is not using a web browser but a custom
+ application, upload the file in smaller chunks.
+
+I've tried uploading large files in 4MB chunks from multiple clients
+at the same time and the memory usage stayed bounded.
+
+Oh, and, as that buffer is allocated when reading the request, if you
+set that limit too high, you will be subject to denial of service
+attacks by anyone that posts a big content length a few times...
+
+