This would be a pretty easy question to answer.
I have inherited a project involving MSMQ. The program sends confirmation messages to an external message sender. So my question is that when my program sends out the confirmation MSMQ Message to the sender, if the message has been sent successfully, then the Outgoing Queue would be empty correct?
My knowledge is that if there are any messages accumulated in the Outgoing Queue, then they have not been sent for whatever reason.
My knowledge is that if there are any messages accumulated in the
Outgoing Queue, then they have not been sent for whatever reason.
No, it means that either:
1 - a message hasn't been sent at all (usually outgoing queue status is "waiting to connect")
or
2 - a message has been sent but no acknowledgement has been received from destination (usually outgoing queue status is "connected")
So, if you are seeing messages delivered in the destination queue then it is (2).
Check the outgoing queues on the destination machine - there should be an outgoing queue pointing back to the original machine that contains the undelivered acknowledgments.
Related
I have a message a want to dequeue then right after its dequeued I want to queue another message to a different queue. I want to do all this in the same transaction. is this possible with rabbitmq or any other queueing service?
The closest you can get to what you want with RabbitMQ is:
Use acks and publisher confirms
You receive a message and do not ack it.
Send your reply message.
Wait for confirm from the broker.
Once confirm had arrived, ack initial message.
But then, consider this failure situation:
Initial message received
Reply message sent
Your service failed before ACKing initial message
When your service is back, it will receive the initial message again
So you will need to use some deduplication mechanism etc.
My goal is to send the same message continuously (if possible to retransmit immediately after the previous transmission is completed) using a UDP protocol until I receive an acknowledgement from the receiver so that I stop transmitting the same message.
However, before retransmitting I would like to know if my previous message has left my NIC succesfully (I do not need to know if it has arrived succesfully to the receiver) so that I am sure that I do not retransmit while the previous message is waiting at the NIC buffer. Is there a way to receive a type of acknowledegement from my NIC when my packet leaves the NIC?
I am using org.hornetq.api.core.client
how can I guarantee the message that I am sending actually reached the queue (not the client, just the queue) ?
producer.send("validQueue",clientMessage)
please note that the queue is a valid queue .
this similar question is referring to invalid queue. other ones such as this one is relevant to the delivery to the client .
It really depends on how you are sending.
First question of yours was about
First of all, on JMS you have to way to send to an invalid queue since the producer will validate the queue's existence. On HornetQ core api you send to an address (not to a queue), and you may have an unbound queue. So you have to query if the address has queues or not.
Now, for confirmation the message was received:
Scenario I, persistent messages, non transactionally
Every message is sent blocked. The client will unblock as soon as the server acknowledged receiving the message. This is done automatically.. you don't have to do anything.
Scenario II, non persistent messages, non transactionally
There are no confirmations by default. The message is sent asynchronously. We assume the message is transient and it's not a big deal if you lost it. you can change that by setting block-on-non-persistent-send on the ServerLocator.
Scenario III, transactionally (either persistent or not).
As soon as you call commit the message is on the queues.
Scenario IV, Confirmation send
You set a callback and you get a method call as soon as the server acked it on the queues. Look on the manual for confirmation callback. There's also the same feature on JMS2.
I'm transferring our web application to new infrastructure and I'm stuck at the MSMQ part.
1st screenshot: Server A sends messages to server B. I see the outgoing messages appear on server A.
2nd screenshot: Server B shows incoming traffic, but the messages don't appear in the queue.
The service picking up the messages at server B is not running!
Any ideas how to debug this situation?
The status of the outgoing queue is connected but the messages aren't moving. Likely to be that the acknowledgement messages are not being sent back successfully from server B. As server A never sees the acknowledgements, it is stuck in a permanent state of retrying to send awaiting a response. There should be an outgoing queue on server B pointing back to server A. Check its status. It is very likely that the IP address of the outgoing queue is incorrect.
If the messages are queuing in your outgoing queue on server A that means that they are definitely not being sent to the destination queue on server B.
If you have messages arriving on server B but not being delivered then this is probably due to queue permissions. However, based on your assertion that messages queue up on the outbound queue I can't see how server B can be receiving any messages.
I have a strange issue setting up an existing application on our new internal Cloud.
I have a simple messaging system that pushes a message from one server (Server1) onto a MSMQ on another server (Server2). The messages disappear off the outbound but never appear in the inbound queue.
When I take Server2 msmq off line the messages build up on Server1. Restarting Msmq on Server2 causes the messages in the outbound queue on Server1 to disappear - but the message still never arrives at Server2.
The details:
MSMQ is set up in Workgroup mode, as that's the virtual networks requirement.
Queues are private.
Permissions are set to allow certain users access.
Has anybody any ideas on why this is happening or how I could track down the issue.
It could be that the remote private queue is a transactional queue and you send the message as non-transactional or vice versa. If the transaction setting on the queue and the message does not match, the message will disappear!
I have seen this in the past with the direct format name where it was set to something like
DIRECT=OS:192.16.8.0.1\PRIVATE$\MyQueue
where I should have specified DIRECT=TCP:192.168.0.1\PRIVATE$\MyQueue
see:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms700996(v=vs.85).aspx
#John Breakwell had noted here http://blogs.msdn.com/b/johnbreakwell/archive/2010/01/22/why-does-msmq-keep-losing-my-messages.aspx:
Server name used to address message doesn't match destination machine
When MSMQ receives a message from over the wire, it always validates that this machine is the correct recipient. This is to ensure that something like a DNS misconfiguration does not result in messages being delivered to the wrong place. The messages are, instead, discarded unless the IgnoreOSNameValidation registry value is set appropriately. You may want to do this with an Internet-facing MSMQ server, for example, where the domain and server names visible to MSMQ clients on the Internet often bear no resemblance to the real ones (for good security reasons).
It sounds like a permissions or addressing issue.
Try to enable the event log under Applications and Services Logs -> Microsoft -> Windows -> MSMQ called End2End.
This log should tell you exactly what is going wrong with the delivery of messages to the expected destination queue.
Nope: For every successful delivery there should be three events raised in this log:
Message with ID blah came over the network (ie, message has arrived from a remote sender)
Message with ID blah was sent to queue blah (ie, message forwarded to local queue)
Message with ID blah was put into queue blah (ie, message arrives in local queue)
Assumes you are using Server 2008 and above.
You can add Negative Source Journaling to the sending application code to find out exactly what the root cause is. Most likely one of the two answers you have already received.
Are the messages arriving in the dead-letter queue on Server 2?