Using MessageQueues, we found that for a PC in a Windows WorkGroup we had to use 'private' message queues, not 'public'.
I think the reason is: With WorkGroup mode queueing, Active Directory is not available, so you are forced to use private queues.
The path for public queues is very different than for private queues:
path to a public queue:
[hostName]\[publicQueueName]
path to a private queue:
FormatName:DIRECT=OS:[hostName]\private$\[queueName]
Depending on how screwed up your network is, you may want to avoid machine name resolution, and use IP addresses:
FormatName:DIRECT=TCP:[ipAddress]\private$\[privateQueueName]
Now if your network is heavily firewalled (or for a developer, just REALLY screwed up), you will have reopen the ports used by MSMQ. For best performance with MSMQ pinging, just open up the lot:
firewalls:
http://support.microsoft.com/kb/183293
ports:
http://support.microsoft.com/kb/178517
With MSMQ3.0 (on Windows 2003 + Windows XP Pro) there is also support for HTTP(s) protocol:
FormatName:DIRECT=HTTP://[myUrl]/private$/[privateQueueName]
Also found what seems to be a bug in .NET 2.0 MesssageQueue:
MessageQueue.Exists() cannot seem to parse a private path.
So, wrote this method to check if a queue exists:
private void messageQueueExists(string _path)
{
try
{
//First try using MessageQueue.Exists()
if (!MessageQueue.Exists(_path))
{
string message = string.Format("\n\rMessage Queue '{0}' does not exist or you do not have access rights to it. \nUse the Control Panel to create and/or set access rights to it.",
_path);
throw new Exception(message);
}
}
catch (InvalidOperationException ex)
{
try
{
//The path could be a private path.
//MessageQueue.Exists() does not work with private paths.
//In order to avoid parsing the path, we can simply try to peek the MSMQ:
MessageQueue msmq = new MessageQueue(_path);
msmq.Peek(new TimeSpan(0, 0, 1));
}
catch (MessageQueueException me)
{
if (me.MessageQueueErrorCode != MessageQueueErrorCode.IOTimeout)
{
throw me;
}
}
}
}
Presumably this is because MessageQueue is basically just a wrapper class ...
I think the reason is: With WorkGroup mode queueing, Active Directory is not available, so you are forced to use private queues.
The path for public queues is very different than for private queues:
path to a public queue:
path to a private queue:
FormatName:DIRECT=OS:[hostName]
Depending on how screwed up your network is, you may want to avoid machine name resolution, and use IP addresses:
FormatName:DIRECT=TCP:[ipAddress]
Now if your network is heavily firewalled (or for a developer, just REALLY screwed up), you will have reopen the ports used by MSMQ. For best performance with MSMQ pinging, just open up the lot:
firewalls:
http://support.microsoft.com/kb/183293
ports:
http://support.microsoft.com/kb/178517
With MSMQ3.0 (on Windows 2003 + Windows XP Pro) there is also support for HTTP(s) protocol:
FormatName:DIRECT=HTTP://[myUrl]
Also found what seems to be a bug in .NET 2.0 MesssageQueue:
MessageQueue.Exists() cannot seem to parse a private path.
So, wrote this method to check if a queue exists:
private void messageQueueExists(string _path)
{
try
{
//First try using MessageQueue.Exists()
if (!MessageQueue.Exists(_path))
{
string message = string.Format("\n\rMessage Queue '{0}' does not exist or you do not have access rights to it. \nUse the Control Panel to create and/or set access rights to it.",
_path);
throw new Exception(message);
}
}
catch (InvalidOperationException ex)
{
try
{
//The path could be a private path.
//MessageQueue.Exists() does not work with private paths.
//In order to avoid parsing the path, we can simply try to peek the MSMQ:
MessageQueue msmq = new MessageQueue(_path);
msmq.Peek(new TimeSpan(0, 0, 1));
}
catch (MessageQueueException me)
{
if (me.MessageQueueErrorCode != MessageQueueErrorCode.IOTimeout)
{
throw me;
}
}
}
}
Presumably this is because MessageQueue is basically just a wrapper class ...
Comments
Post a Comment