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

[bugzilla-daemon@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 jrodman@ximian-bugzilla.spamportal.net.

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

--- shadow/71001	2005-01-04 16:45:56.000000000 -0500
+++ shadow/71001.tmp.27508	2005-01-04 16:45:56.000000000 -0500
@@ -0,0 +1,48 @@
+Bug#: 71001
+Product: Mono: Tools
+Version: 1.0
+OS: SLES 9
+OS Details: AMD-64
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Blocker
+Component: XSP
+AssignedTo: gonzalo@ximian.com                            
+ReportedBy: jrodman@ximian-bugzilla.spamportal.net               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: xsp.exe virtual size grows without bound -- large messages
+
+We're using xsp to host a relatively trivial SOAP-based web service
+which receives binary files.  The files are sent as byte[] arrays in
+single calls.  This uses a fair amount of memory, and may not be
+optimally efficient, but for our purposes that's probably fine, and
+there are significant reasons to be using as vanilla SOAP as possible.
+
+Particulars: This is an Opteron box, with one gig of ram, running SuSE
+        Linux Enterprise Server 9, mono 1.0.5 from downloaded (binary)
+        x86 packages.
+xsp.exe's virtual size grows larger with every data transmission.  After
+enough transactions, xsp will begin to swap heavily, and the time to
+transmit will go from on the order of 1 second per megabyte of data down
+to as bad as 15 seconds per megabyte of data.  I'm sure it will only get
+worse but when my shell and X session and so on have all long since
+beeen swapped it I lose patience with exploring the extent of the
+problem.
+
+It's possible this is some foolish newbie mistake, but I've tried to
+strip it down to the absolute minimum and sanity check my understanding
+of everything I'm doing with peers, and I really don't think so.
+
+----------------
+
+Later, we reclaimed significant memory from other processes and had about
+500-600 megabytes of real RAM for XSP to play with.  It would happily fill
+the entirety of this space before performance would begin to rapidly drop,
+presumably beginning to internally swap.
+
+-------------
+The test case is attached.