Calling Dispose() on the message objects did the trick. I'm still concerned about my ability to run low on virtual memory. Message should clean up after itself when GC'd, including unmanaged resources, no? And, IMO, running out of virtual memory is a pretty good clue to fire up the Finalize calls on all those Message objects which went out of scope. Am I misunderstanding something here?
In any case, now I know to call dispose on Message objects, and now I must generalize: System.Messaging.Message implements IDisposable. Is it Good Practice to always call Dispose() on objects which implement IDisposable? Smiling, as directed, -Ed Evans -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]]On Behalf Of Ed Stegman Sent: Monday, June 03, 2002 11:54 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] GC asleep at the wheel I'm not so sure about that. He (the other Ed) indicated his array length was 50 or less items, and that normally the whole app wouldn't exceed 5MB. The high priority issue[1] is with the large object heap. IIRC the LOH is for array allocations exceeding 8 MB's. Obviously, the code you posted isn't your actual working code. Look through your working code and verify you aren't inadvertently holding a reference to the arrays or the Message objects some place, and to ensure you are calling Dispose() on the Message objects as soon as you are finished with them. For example: string foo = m.Body; m.Dispose(); Keep Smilin' Ed Stegman [1] The issue surfaced over 5 months ago and has yet to be addressed in a service pack. That's gotta be one tough bug! -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]]On Behalf Of Katie Kenny Sent: Monday, June 03, 2002 1:46 PM To: [EMAIL PROTECTED] Subject: Re: GC asleep at the wheel 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. 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.
