Ed, I believe the problem you're observing is related to a discussion on the other Dot Net list.
According to Serge Linden and company, there is a known bug with the gc reclaiming space allocated to arrays. Per the link below, this is a high priority issue for Microsoft. http://discuss.develop.com/archives/wa.exe?A2=ind0202A&L=DOTNET&D=0&P=13700 hth, Katie -----Original Message----- From: Edward Evans [mailto:[EMAIL PROTECTED]] Sent: Monday, June 03, 2002 12:17 PM To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] GC asleep at the wheel I have an MSMQ client app which basically does this (sorry for the psueso-psuedo-code): TimeSpan timeout = new TimeSpan( 0, 0, 1, 0, 0 ); while( true ) { try { Message m = messageq.Receive( timeout ); MyType[] mytype = (MyType[])m.Body; } catch( MessageQueueException e ) { if( e.MessageQueueErrorCode == MessageQueueErrorCode.IOTimeout ) continue; else return; } } The app memory usage climbs while running and consuming messages, eventually peaking at ~130 when the queue is emptied. The length of the mytype array is 50 or less, and MyType is a quite small as well. Ordinarly this app wouldn't run over 5MB. My guess was the GC just didn't have a chance to cleanup, but once the queue is empty the app sits idle in one minute intervals waiting for new messages - and yet the memory stays up, sometimes for half an hour. Once the the GC fires, the memory drops to ~1MB. I know it's a no-no to force the GC, so is there something I could fix in my coding style? When I ran this against a very large set of messages I actually got a "running low on virtual memory" from windows, so I need to so something different. Thanks, -Ed Evans You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
