Has anyone taken a look at the patch I submitted for QPID-345 yet? (Blocking receive modes in BasicMessageConsumer).
Granted, it's not the most elegant patch, but it seems to do the trick and simplify the current code a bit. On a related topic, looking around it seems that most of the .NET client code handles Timeout values as longs, possibly to match the original Java code. However, one thing worth pointing out (and that I had to deal a bit with in my patch) is that the convention in .NET is to deal with timeout values as Int32 values or (even better) as TimeSpan values. A lot of this has to do with the fact that usually these timeout values end up being handed down to WaitHandles (like synchronization primitives), all of which handle timeouts as Int32 values because the underlying Win32 APIs on which they were models use that as well. Any thoughts? Tomas Restrepo [EMAIL PROTECTED] http://www.winterdom.com/weblog/
