http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Wow this is ugly. I agree with Omer the only sensible way to deal with this is to wrap it in another class. Seem to me we have to provide our own synchronization before calling Dispose and other methods. It's probably hard for you to reproduce this bug because, I think, it is a very rare case for a deadlock to happen. http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment14http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment14Sat, 24 Jan 2009 20:23:36 GMTI too was bitten occasionally by the poor multi threading support of the MessageQueue class. An idea popped to my mind now: Why not wrap this class with another that provides better disposal handling? ReSharper has the "Generate Delegating Members" feature that can help wrapping easily. http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment13http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment13Sat, 24 Jan 2009 07:27:12 GMTThe problem is you still need to re-initialize the queue so that it can handle the peek command. You expected the ObjectDisposedException to be thrown, so instead of catching the exception, check if the queue disposed. The problem with the Disposing that I can see: - There's always a very high chance that disposed state is not always checked by classes. - Developers must be careful to call Dispose once, and only once, or nasty bugs will jump out. So I think you should always check if the queue is disposed, just like you have to have nasty null checks. http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment12http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment12Sat, 24 Jan 2009 06:47:22 GMTI _said_ that this is gmail code. http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment11http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment11Sat, 24 Jan 2009 06:43:25 GMTor are you saying it would still fail to return? if that's the case, i wish i could say i was shocked. i feel like system.messaging has probably not had the attention paid to it that it should with the ascent of wcf. http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment10http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment10Sat, 24 Jan 2009 06:34:36 GMTah, i never do a begin* without a timeout when i am dealing with msmq. i tend to also keep them very low. http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment9http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment9Sat, 24 Jan 2009 06:33:37 GMTThe problem isn't the message handling. The problem is code like this (gmail code): public void RegisterForMessageProcessing() { queue.BeginPeek( ar => { var msg = queue.EndPeek(ar); RegisterForMessageProcessing(); // do something with message }); ) It is possible to get into a situation where you call BeginPeek and it never returns. That is a problem http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment8http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment8Sat, 24 Jan 2009 06:21:55 GMTi do the actual message dispatch in a thread pool, so we spend very little time in the async callbacks. http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment7http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment7Sat, 24 Jan 2009 06:15:53 GMTSmhinsey, It doesn't work like that when you want to be able to process messages from the queue on multiple threads. http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment6http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment6Sat, 24 Jan 2009 05:58:02 GMTthe way i avoided this was to adopt a threading model where one thread owns a queue and when you want to stop processing it, you send it a contol message, so you never directly interact with a queue from a thread that doesn't own it. http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment5http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment5Sat, 24 Jan 2009 05:14:27 GMTChris, No, dispose is called BEFORE BeginPeek. The problem is that it happens in two different threads Tran, That is not always possible in a multi threaded applications. http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment4http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment4Sat, 24 Jan 2009 04:08:38 GMTYour code is not supposed to use any object after it's disposed. It's true that ObjectDisposedException should be thrown, but sometimes developer forget to put a check in methods. I have never had any check for disposed state in my classes and in my team, everyone have to make sure not to use a disposed object, mostly using IsDisposed property. Most of the time I will unsubscribe from object's events before it's disposed to make sure that instance will not give me a surprise"tada". http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment3http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment3Sat, 24 Jan 2009 03:57:43 GMTmsmq can definitely be a headache with this stuff. i address this by building into the system the assumption that processing on a queue will not stop until the current message(s) are finished processing. i'm not sure that i understand your explanation enough to say that you're in the same situation. http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment2http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment2Sat, 24 Jan 2009 03:11:56 GMTIs the Dispose supposed to be after the BeginPeek in your example? And I've also seen some really strange behavior with MessageQueue and asynchronous operations. Probably has to do with all the COM glue that .NET goes through to talk to MSMQ. I remember having to go into reflector to figure it out one time. http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment1http://ayende.com/3828/more-disposal-subtleties-and-framework-bugs-that-stalks-me#comment1Sat, 24 Jan 2009 02:19:16 GMT