views:

73

answers:

2

Is there any way to check if a public MSMQ is empty? For a private MSMQ it's easy:

private bool IsQueueEmpty(string path)
        {
            bool isQueueEmpty = false;
            var myQueue = new MessageQueue(path);
            try
            {
                myQueue.Peek(new TimeSpan(0));
                isQueueEmpty = false;
            }
            catch (MessageQueueException e)
            {
                if (e.MessageQueueErrorCode == MessageQueueErrorCode.IOTimeout)
                {
                    isQueueEmpty = true;
                }
            }
            return isQueueEmpty;
        }

How would I do the same check for a public MSMQ? If I try to check a public MSMQ with the code above it gives me an error on the Peak:

System.ArgumentOutOfRangeException: Length cannot be less than zero.

+1  A: 

The Peek method is only available on remote machines when you use a direct format name to access the queue. You should be able to use the same code, so long as you're not relying on directory services to get you to the queue.

Direct queue names generally look something like: DIRECT=URLAddressSpecification/QueueName

LBushkin
Thanks for the response. I thought every public queue uses directory services?? I changed the path to DIRECT=TCP:myip\mypublicqueue but it gives me: The queue does not exist or you do not have sufficient permissions to perform the operation
Justin
@Justin: The direct name would be something like: `DIRECT=OS:servername\public$\mypublicqueuename` or `DIRECT:TCP:ipaddress\public$\mypublicqueuename`. You can search MSDN for the specific direct format name to use - it can vary by OS version, and other factors.
LBushkin
A: 
John Breakwell
`isQueueEmpty` is a boolean - I doubt it's raising an exception. As for the limitations of `Peek` - I can't find the documentation right now, but I'm pretty sure there's a table or something that identifies when `Peek` is available.
LBushkin
Ah, of course, I misread the code. No wonder I couldn't find isQueueEmpty in the docs! Apologies.
John Breakwell