[Mono-bugs] [Bug 59624][Cri] Changed - Remoting over HTTP creates new thread for each request.

[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 lluis@ximian.com.

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

--- shadow/59624	2004-06-07 19:14:03.000000000 -0400
+++ shadow/59624.tmp.12749	2004-06-08 13:15:37.000000000 -0400
@@ -473,6 +473,42 @@
 will fix some memory leaks in some scenarios.
 
 ------- Additional Comments From lluis@ximian.com  2004-06-07 19:14 -------
 Created an attachment (id=8051)
 Fixed and simplified test case.
 
+
+------- Additional Comments From lluis@ximian.com  2004-06-08 13:15 -------
+Status summary:
+
+1) I can't find any relation between thread creation and memory leaks.
+
+2) Two memory leaks have been fixed lately. One related to object
+lifetime and another one in Char.ToUpper/ToLower.
+
+3) With current CVS, I can run the your test case with the modified
+InitializeLifetimeService() method for two hours and memory usage
+stabilizes at 31Mb.
+
+4) This amount of memory will vary depending of how fast the test is
+run. For example, if I remove the GetData/PutData calls from the test,
+memory usage stabilizes at aroung 220Mb. This has an easy explanation:
+the server holds a reference to published remote objects until its
+lifetime expires, and the GC can't collect those objects until that
+reference is released. The Lifetime service checks for expired objects
+every 10 seconds. It means that the server will keep in memory all
+objects requested by the client in 10 seconds, plus the extra time
+until the GC decides to collect the object (which is unpredictable).
+
+I've been able to verify that there isn't any other memory leak. I run
+the test without the GetData/PutData calls and when it reached those
+220mb I forced several garbage collections and run a GC diagnostic
+method. This method reported that the GC had around 2Mb of objects and
+around 216Mb in its free memory list. It means that there are no
+managed memory leaks (only 2mb are allocated), and no unmanaged memory
+leaks (since the allocated+free gc memory is almost the total process
+memory). It also means that the GC is not managing very well the
+memory in this case.
+
+Can you please update from cvs and check if the patches have also
+fixed the problem in iFolder?
+