Not Receiving Acknowledgements

[garydbutler]

I'm sending messages over HTTP and they are being received by the receiver.
However, the acknowledgements aren't being returned. When I send the message
I create a new adminqueue object and attach to the message. The admin queue
is created on the sender as follows:

MessageQueue AdminQ = new MessageQueue(".\private$\adminqueue");

msg.AdministrationQueue = AdminQ;

I am setting the acknowledgetypes to fullreachqueue | notacknowledgereachqueue

When I check the adminstrationqueue object attached to the received message
on the receiver, the formatname of the adminqueue is
"Direct:OS=EntServer\private$\adminqueue"

I understand why the format name is as it is and I understand why the
receiver can't send back to that queue because it is unreachable over the
internet using a local address.

The question is how should I create the admin queue object in order to have
the message returned? Is there a mapping I can use on the receiving computer
to map the admin queue to the proper http:// format name?

Thanks in advance,

Gary B.

[Frank Boyne]

Post by garydbutler
MessageQueue AdminQ = new MessageQueue(".\private$\adminqueue");
msg.AdministrationQueue = AdminQ;

Try this...

MessageQueue AdminQ = new MessageQueue
(@"formatname:DIRECT=http://EntServer/msmq/private$/adminqueue");
msg.AdministrationQueue = AdminQ;

... or this ...

MessageQueue AdminQ = new MessageQueue
(@"formatname:DIRECT=http://./msmq/private$/adminqueue");
msg.AdministrationQueue = AdminQ;

The first approach is easier to read but hard-codes the host name
"EntServer". The second approach is more portable. On EntServer it
will generate the exact same format name as the period will be channged
to 'EntServer'.

Post by garydbutler
Is there a mapping I can use on the receiving computer
to map the admin queue to the proper http:// format name?

I don't believe so. The problem is that mappings are part of a
mechanism known as HTTP Message Redirection. a queue name has to be in
HTTP form before an HTTP message will be created and a message has to be
an HTTP message before it can be redirected.
http://technet2.microsoft.com/windowsserver2008/en/library/a2fcb902-855f-48e8-921d-69cd311a1dbd1033.mspx

For my own curiousity, what OS is your receiver running? My receiver is
running Vista and it rejects HTTP messages with admin queue names that
are anything other than HTTP based.

[garydbutler]

I'll give that a try.

Both ends are running Windows XP Pro SP2.

Post by Frank Boyne

Post by garydbutler
MessageQueue AdminQ = new MessageQueue(".\private$\adminqueue");
msg.AdministrationQueue = AdminQ;

Try this...
MessageQueue AdminQ = new MessageQueue
msg.AdministrationQueue = AdminQ;
.... or this ...
MessageQueue AdminQ = new MessageQueue
msg.AdministrationQueue = AdminQ;
The first approach is easier to read but hard-codes the host name
"EntServer". The second approach is more portable. On EntServer it
will generate the exact same format name as the period will be channged
to 'EntServer'.

Post by garydbutler
Is there a mapping I can use on the receiving computer
to map the admin queue to the proper http:// format name?

I don't believe so. The problem is that mappings are part of a
mechanism known as HTTP Message Redirection. a queue name has to be in
HTTP form before an HTTP message will be created and a message has to be
an HTTP message before it can be redirected.
http://technet2.microsoft.com/windowsserver2008/en/library/a2fcb902-855f-48e8-921d-69cd311a1dbd1033.mspx
For my own curiousity, what OS is your receiver running? My receiver is
running Vista and it rejects HTTP messages with admin queue names that
are anything other than HTTP based.

[garydbutler]

Still no luck. I created the admin queue as you suggested:

(@"formatname:DIRECT=http://./msmq/private$/adminqueue");

msg.AdministrationQueue = AdminQ;

msg.AcknowledgeType = AcknowledgeTypes.FullReachQueue;

and when the message is received by the receiver, the attached
administration queue has the proper http formatname to reach the sender's
admin queue.

I am receiving messages from the remote application that I'm trying to get
these acks from (it's used to send data to my server periodically and to
receive messages from my server) and it receives messages from my server.
However, I can't find the ack messages anywhere.

Post by Frank Boyne

Post by garydbutler
MessageQueue AdminQ = new MessageQueue(".\private$\adminqueue");
msg.AdministrationQueue = AdminQ;

Try this...
MessageQueue AdminQ = new MessageQueue
msg.AdministrationQueue = AdminQ;
.... or this ...
MessageQueue AdminQ = new MessageQueue
msg.AdministrationQueue = AdminQ;
The first approach is easier to read but hard-codes the host name
"EntServer". The second approach is more portable. On EntServer it
will generate the exact same format name as the period will be channged
to 'EntServer'.

Post by garydbutler
Is there a mapping I can use on the receiving computer
to map the admin queue to the proper http:// format name?

I don't believe so. The problem is that mappings are part of a
mechanism known as HTTP Message Redirection. a queue name has to be in
HTTP form before an HTTP message will be created and a message has to be
an HTTP message before it can be redirected.
http://technet2.microsoft.com/windowsserver2008/en/library/a2fcb902-855f-48e8-921d-69cd311a1dbd1033.mspx
For my own curiousity, what OS is your receiver running? My receiver is
running Vista and it rejects HTTP messages with admin queue names that
are anything other than HTTP based.

[Frank Boyne]

Post by garydbutler
and when the message is received by the receiver, the attached
administration queue has the proper http formatname to reach the sender's
admin queue.

We're making _some_ progress at least.

Post by garydbutler
I am receiving messages from the remote application that I'm trying to get
these acks from (it's used to send data to my server periodically and to
receive messages from my server) and it receives messages from my server.

Do these messages use the same EntServer hostname when constructing the
format name used to send these messages? It might be worth constructing
a quick test script to send a message to the actual admin queue using
the actual format name just to check the format name works. Something
like this should do the trick...

Option Explicit

Dim qi
set qi = WScript.CreateObject("MSMQ.MSMQQueueInfo")
qi.FormatName = "DIRECT=http://EntServer/msmq/private$/adminqueue"

Dim q
set q = qi.Open(2,0) ' MQ_SEND_ACCESS,MQ_DENY_NONE

Dim msg
set msg = WScript.CreateObject("MSMQ.MSMQMessage")

msg.Body = "VBScript test message (msmqsend.vbs)" + String (200, "*")
msg.Label = "VBScript test message Label (msmqsend.vbs)"
msg.Journal = 1 ' MQMSG_DEADLETTER

msg.Send q

q.Close()

Store the script above in a file with a .vbs extension (e.g., test.vbs)
and then run the script on your receiver system from a Command Window
using the command cscript test.vbs. At minimum you should get an
outgoing queue on the Receiver system containing the test message.
Ideally you should get an empty outgoing queue and a test message in teh
actual admin queue.

Post by garydbutler
However, I can't find the ack messages anywhere.

It would probably be good to figure out whether or not the ack messages
are even being sent (though I can't think of a good reason for them not
to be sent). Here's one way. On EntServer, run the IIS manager (under
Administrative Tools) then find the Default site. Right click on the
default site and select Stop. Now MSMQ messages cannot be delivered to
this system (MSMQ is an application under the default site) but MSMQ
messages can still be sent from it.

If necessary, change your application to use Acknowledgement =
FullReachQueue to ensure an acknowledgement message is sent then run
your application and send a message. The message should end up in the
queue on your destination system, and an ack should be generated. Since
the ack can't be delivered to EntServer it should sit in an outgoing
queue on the destination system.

If you run Computer Management on the receiver system you should be able
to find an outgoing queue pointing at your admin queue on EntServer with
an acknowledgement message in it. Now, in IIS Manager back on EntServer
start the Default Site again. Eventually, the outgoing queue on the
receiver system should empty as the ack message is delivered to
EntServer (and, once the outgoing queue has been empty for a while, the
outgoing queue will disappear). Once the outgoing queue is empty (or
gone) we can assume the message has been transferred and should be found
in the Admin Q.

Assuming an ack message is generated and (eventually) disappears from
the outgoing queue but does not show up in the admin queue we can
probably assume some sort of delivery problem. Either the message is
being delivered to the wrong system or it is being delivered correctly
and _still_ can't be placed into the queue.

Causes for delivering to the wrong system would include things like DNS
resolving the EntServer name to the wrong IP address (but it would have
to be the IP address of another system running MSMQ). Causes for
delivering okay but not reaching the queue would include things llike
the queue security not allowing the sender to have Send access to the
queue. In this case I think the sender would be "Anonymous Logon" so you
might check that the admin queue's permissions grant Send access to
Anonymous Logon. Note that granting "Everyone" access is usually not
sufficient because by default "Everyone" does not include "Anonymous
Logon" - although you can change that via policy.

[garydbutler]

Thanks for the VBS, I wouldn't have thought of that.

It turns out that I needed to add another entry to my mapping.xml file in
the c:\windows\system32\msmq\mapping folder of the sending machine. I had
already done that for the message queue that I'm listening on and wasn't
thinking about it for the admin queue. My mapping.xml file now looks like
this:

<mapping host="localhost" xmlns="msmq-queue-mapping.xml">
<!-- Element that maps an internal application queue name to an external
one. -->

<queue>
<name>http://192.168.1.99/msmq/private$/adminqueue</name>
<alias>http://entserver.xxxxx.com/msmq/private$/adminqueue</alias>
</queue>

<queue>
<name>http://192.168.1.99/msmq/private$/iBistroEnterprisePolling</name>

<alias>http://entserver.xxxxx.com/msmq/private$/iBistroEnterprisePolling</alias>
</queue>

</mapping>

However, I did run into one other issue that I need to play around with. As
you suggested, I was using the http://./msmq/private$/adminqueue formatname
and I did receive an ack for the first message that I sent. Following
messages didn't receive acks though. When I checked the receiver, there was
a message in the outgoing queue with the formatname of
http://./msmq/private$/adminqueue


I'll runs some more tests and see what I did wrong but it looks like I'm
back on track.

For background, the solution that I'm working will be used by remote sites
to send data collected periodically to an enterprise server (entserver).
Entserver will store this data to a SQL Server database for reporting.

The EntServer will also be able to send messages and transfer files via msmq
to the remote sites. This is the scenario I was working on when I hit the
acknowledgement snag.

Thanks again for the help.

Gary B.

Post by Frank Boyne

Post by garydbutler
and when the message is received by the receiver, the attached
administration queue has the proper http formatname to reach the sender's
admin queue.

We're making _some_ progress at least.

Post by garydbutler
I am receiving messages from the remote application that I'm trying to get
these acks from (it's used to send data to my server periodically and to
receive messages from my server) and it receives messages from my server.

Do these messages use the same EntServer hostname when constructing the
format name used to send these messages? It might be worth constructing
a quick test script to send a message to the actual admin queue using
the actual format name just to check the format name works. Something
like this should do the trick...
Option Explicit
Dim qi
set qi = WScript.CreateObject("MSMQ.MSMQQueueInfo")
qi.FormatName = "DIRECT=http://EntServer/msmq/private$/adminqueue"
Dim q
set q = qi.Open(2,0) ' MQ_SEND_ACCESS,MQ_DENY_NONE
Dim msg
set msg = WScript.CreateObject("MSMQ.MSMQMessage")
msg.Body = "VBScript test message (msmqsend.vbs)" + String (200, "*")
msg.Label = "VBScript test message Label (msmqsend.vbs)"
msg.Journal = 1 ' MQMSG_DEADLETTER
msg.Send q
q.Close()
Store the script above in a file with a .vbs extension (e.g., test.vbs)
and then run the script on your receiver system from a Command Window
using the command cscript test.vbs. At minimum you should get an
outgoing queue on the Receiver system containing the test message.
Ideally you should get an empty outgoing queue and a test message in teh
actual admin queue.

Post by garydbutler
However, I can't find the ack messages anywhere.

It would probably be good to figure out whether or not the ack messages
are even being sent (though I can't think of a good reason for them not
to be sent). Here's one way. On EntServer, run the IIS manager (under
Administrative Tools) then find the Default site. Right click on the
default site and select Stop. Now MSMQ messages cannot be delivered to
this system (MSMQ is an application under the default site) but MSMQ
messages can still be sent from it.
If necessary, change your application to use Acknowledgement =
FullReachQueue to ensure an acknowledgement message is sent then run
your application and send a message. The message should end up in the
queue on your destination system, and an ack should be generated. Since
the ack can't be delivered to EntServer it should sit in an outgoing
queue on the destination system.
If you run Computer Management on the receiver system you should be able
to find an outgoing queue pointing at your admin queue on EntServer with
an acknowledgement message in it. Now, in IIS Manager back on EntServer
start the Default Site again. Eventually, the outgoing queue on the
receiver system should empty as the ack message is delivered to
EntServer (and, once the outgoing queue has been empty for a while, the
outgoing queue will disappear). Once the outgoing queue is empty (or
gone) we can assume the message has been transferred and should be found
in the Admin Q.
Assuming an ack message is generated and (eventually) disappears from
the outgoing queue but does not show up in the admin queue we can
probably assume some sort of delivery problem. Either the message is
being delivered to the wrong system or it is being delivered correctly
and _still_ can't be placed into the queue.
Causes for delivering to the wrong system would include things like DNS
resolving the EntServer name to the wrong IP address (but it would have
to be the IP address of another system running MSMQ). Causes for
delivering okay but not reaching the queue would include things llike
the queue security not allowing the sender to have Send access to the
queue. In this case I think the sender would be "Anonymous Logon" so you
might check that the admin queue's permissions grant Send access to
Anonymous Logon. Note that granting "Everyone" access is usually not
sufficient because by default "Everyone" does not include "Anonymous
Logon" - although you can change that via policy.