[Mono-bugs] [Bug 71001][Nor] Changed - 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 matt.hargett@logiclibrary.com.

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

--- shadow/71001	2005-01-30 14:28:56.000000000 -0500
+++ shadow/71001.tmp.1719	2005-01-31 13:45:28.000000000 -0500
@@ -1,13 +1,13 @@
 Bug#: 71001
 Product: Mono: Runtime
 Version: unspecified
 OS: SLES 9
 OS Details: AMD-64
-Status: RESOLVED   
-Resolution: WONTFIX
+Status: REOPENED   
+Resolution: 
 Severity: Unknown
 Priority: Normal
 Component: misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: jrodman@ximian-bugzilla.spamportal.net               
 QAContact: mono-bugs@ximian.com
@@ -81,6 +81,22 @@
 it is the same issue we have faced in the past due to memory
 fragmentation.
 
 There are other solutions, like what iFolder uses, which is to
 transfer chunks in 64k of data
 
+
+------- Additional Comments From matt.hargett@logiclibrary.com  2005-01-31 13:45 -------
+Does this mean this will remain unresolved even if we purchase the
+mono  incident support and attempt to use it for this issue?
+
+Microsoft .NET does not exhibit this problem, though I seem to recall
+that Windows NT 4.0's heap had this kind of problem up intil SP3 or
+SP4. A similar problem was surmountable in that instance, at least. I
+am curious why it is not in this instance? This seems to be a major
+barrier to mono being used in server-based applications that require a
+decent amount of uptime or scalability.
+
+Nevertheless, we appreciate this issue being investigated and look
+forward to answers to the questions above.
+
+Thanks!