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.
Related
I'm trying very hard to understand the flow of a web request to a server which has a queue or message broker in the middle, but I can't find information about when and where the reply is given.
Imagine this use case:
Client A:
sends a invoice order request
the invoice is enqueued
the request is processed and dequeued.
at which time the client will receive a response?
right after the message is received by the queue?
right after the message is processed and dequeued? Other?
I'm asking because if the reply only comes after the message being processed the client might wait a long time. Imagine the message takes 3 minutes to process, would the client need to keep requesting the server to see if it is processed? or a connection is maintained using something like long polling?
I'm interested in scenarios using RabbitMq and kafka.
Advantage of having a messaging system is to ensure the frontend webserver and backend processing is decoupled. Best practice is Web server should publish the message and just wait for the messaging system to acknowledge receiving the message.
At the server, CometD provides a MaxQueueListener hook to drop messages but if the Bayeux Client wants to stop receiving messages from a server without disconnecting , can it achieve that?
A BayeuxClient receives message from the server only for the channels it is subscribed to.
For a BayeuxClient to stop receiving messages from the server is enough to unsubscribe from all channels it subscribed to.
The BayeuxClient will still receive meta messages on meta channels that are part of the Bayeux protocol, but no application message will be delivered by the server.
My system has one server and many clients of 2 types. First type of client sends events to server. Second type receives notifications from server on these events. I'm currently testing RabbitMQ and NServiceBus to build message queue with the following requirements:
First type of client should have incoming queue for events (physically running on it) to prevent data loss on server disconnection.
Server should have outgoing queue for notifications (physically running on it) to prevent data loss on second type client disconnection.
[Client Type 1 + queue] -> [Server + queue] -> [Client Type 2]
Can this be achieved with one of specified components (or both of them)? If yes how?
I am not very familiar with rabbit, so I'll answer the question with nservicebus (NSB) in mind.
My system has one server and many clients of 2 types
OK, first thing, NSB does not have equivalent concepts of client and server. In NSB, all participating applications are called endpoints or services. Some endpoints are publishers, some are subscribers, some are senders, some are receivers. Some are any combination of the above.
First type of client sends events to server.
By convention, there are two types of message in NSB, commands and events. Commands are sent, events are published. So in this scenario, the type 1 clients would send commands to the server. In this scenario, a type 1 client would be a sender endpoint. The server is therefore a receiver endpoint.
Second type receives notifications from server on these events
So in this scenario, the server is a publisher endpoint, and a type 2 client is a subscriber endpoint. The server will publish an event which all subscribers would receive.
First type of client should have incoming queue for events (physically running on it) to prevent data loss on server disconnection
I am assuming that you mean the type 1 client needs to receive the data which it needs to send to the server from somewhere.
Well, in NSB, every endpoint has a queue, called the input queue. This is the means by which the endpoint receives messages.
In NSB the queue transport is abstracted, but out of the box the default is MSMQ (NSB also has support for Rabbit as the queue transport).
This provides a store-and-forward messaging pattern, which guarantees reliability. What this means is that if the server is unavailable, the queuing transport would wait until it was available again before transmitting the message.
So you could send a message onto the type 1 client input queue, which would then be converted into a command and sent to the server.
Server should have outgoing queue for notifications (physically
running on it) to prevent data loss on second type client
disconnection.
Similarly, when the server publishes the event (on receipt of the command from the type 1 client), the queuing transport would guarantee delivery of the event to all the subscribing type 2 clients.
A point of note: this would not be based on the server having an "outgoing queue", but rather the queuing transport would deliver the messages to the input queues of all subscribing endpoints.
So all your scenarios would be satisfied by using NServiceBus as part of your approach.
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.
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?