Using NServiceBus 4.4.2.
When sending to a local recipient and before the Recipient got a chance to run (meaning queues are not there yet) I get a nice exception 'The destination queue "xyz" could not be found'. However, when sending to a recipient on another machine, and Remote recipient hasn't run yet (remote queues are not there yet), there is no exception thrown, no error anywhere on the sender and message is nowhere to be found.
Am I missing something?
The message is in the "Outgoing Queues"
MSMQ uses store-and-forward to reliably send messages to remote queues.
In this case because the remote queue is not available yet, the message will stay in the outgoing queue till either expires or the remote queue becomes available.
Related
I am using graphql-apollo. The client subscribes to some messages and the server, using redis, sends them to the client.
If in the client updateQuery an error is thrown and not catched, can that, somehow, affect the running of the server function publishing the message? Could that server function crash or otherwise not finih correctly?
Thanks.
It should not affect the sender's push/publish capabilities. A message published via PUB/SUB is not persisted so once you consume you have to consume no matter what happens to the consumer, it can't be put back.
This also means, if you're using Redis PUB/SUB to send/receive messages than messages can be lost due to consumer connectivity, if a consumer is down for some time than all messages sent in that window would be lost.
I have a simple question, but I can't find evidence on the internet.
I'm connecting to RabbitMQ with MassTransit, and I just wanted to know if Consumer Acknowledgements and Publisher Confirms is active by default if a connection has been made to the broker using MassTansit?
If active by default: Where can I find evidence about this?
If not active by default: How can I enable these functionalities?
PublisherConfirmation is active by default, and always has been that way. This means that a call to Publish, when awaited, will not complete until the message is confirmed by the broker (ack'd).
Consumers do not ack messages until they are processed by the consumer. If the consumer completes, the ack removes the message. If an exception was thrown, the message is moved to the _error queue and a Fault<T> is published.
My application consumes JMS messages in a Glassfish 3.1.2 server and OpenMQ as JMS provider.
The strange behavior happens when a consumer fails to process a message. In this situation Glassfish correctly move the message to the Dead Message Queue (after 2 attempts). And this is fine.
When I restart the server, the message stored in the DMQ, is sent again to the original destination (and that's ok, althoug I didn't expect this behavior). Now, also if the consumer succeed, the message remains in the destination.
That's incorrect because, after another restart of the server, the message is consumed again. Strangely this time the message is permanently removed from the queue.
The questions are:
why the message remains in the queue?
And why GF try to move automatically the message from the DMQ into the original one, after a restart?
I've got some trouble understanding the confirm of RabbitMQ, I see the following explanation from RabbitMQ:
Notes
The broker loses persistent messages if it crashes before said
messages are written to disk. Under certain conditions, this causes
the broker to behave in surprising ways. For instance, consider this
scenario:
a client publishes a persistent message to a durable queue
a client consumes the message from the queue (noting that the message is persistent and the queue durable), but doesn't yet ack it,
the broker dies and is restarted, and
the client reconnects and starts consuming messages.
At this point, the client could reasonably assume that the message
will be delivered again. This is not the case: the restart has caused
the broker to lose the message. In order to guarantee persistence, a
client should use confirms. If the publisher's channel had been in
confirm mode, the publisher would not have received an ack for the
lost message (since the consumer hadn't ack'd it and it hadn't been
written to disk).
Then I am using this http://hg.rabbitmq.com/rabbitmq-java-client/file/default/test/src/com/rabbitmq/examples/ConfirmDontLoseMessages.java to do some basic test and verify the confirm, but get some weird results:
The waitForConfirmsOrDie method doesn't block the producer, which is different from my expectation, I suppose the waitForConfirmsOrDie will block the producer until all the messages have been ack'd or one of them is nack'd.
I remove the channel.confirmSelect() and channel.waitForConfirmsOrDie() from publisher, and change the consumer from auto ack to manual ack, I publish all messages to the queue and consume messages one by one, then I stop the rabbitmq server during the consuming process, what I expect now is the left messages will be lost after the rabbitmq server is restarted, because the channel is not in confirm mode, but I still see all other messages in the queue after the server restart.
Since I am new to RabbitMQ, can anyone tells me where is my problem of the confirm understanding?
My understanding is that "Channel Confirmation" is for Broker confirms it successfully got the message from producer, regardless of consumer ack this message or not. Depending on the queue type and message deliver mode, see http://www.rabbitmq.com/confirms.html for details,
the messages are confirmed when:
it decides a message will not be routed to queues
(if the mandatory flag is set then the basic.return is sent first) or
a transient message has reached all its queues (and mirrors) or
a persistent message has reached all its queues (and mirrors) and been persisted to disk (and fsynced) or
a persistent message has been consumed (and if necessary acknowledged) from all its queues
Old question but oh well..
I publish all messages to the queue and consume messages one by one, then I stop the rabbitmq server during the consuming process, what I expect now is the left messages will be lost after the rabbitmq server is restarted, because the channel is not in confirm mode, but I still see all other messages in the queue after the server restart.
This is actually how it should work, IF the persistence is enabled. If the server crashes or something else goes wrong, the messages cannot be confirmed, and thus, won't be removed from the queue.
Messages will only be removed from the queue if they are confirmed to be handled, or the broker didn't yet write it to memory or disk before the server crashed.
Confirming and acknowledging can be set off if wanted, and the producer won't be waiting for the acks. I cannot find the exact command for it right now, but it does exist.
More on the acks and confirms: https://www.rabbitmq.com/reliability.html
With simple Pub/Sub in NServiceBus, I know that if my subscriber app is not running, then the published messages will just accumulate in the queue until they can be processed. But where do they accumulate if the entire machine is down? Since the message can't even be delivered to my subscriber queue, is there some queue where they sit on the publisher? I would like to be able to see what messages are waiting on the publisher when the subscriber machine is down.
Is there any way to see them?
Msmq, the default transport for NServiceBus, uses the store and forward pattern to deliver messages. That means that when you send a message to another machine it's first "stored" on the machine that sends the message and then "forwarded" to the recipient machine. This means that outgoing messages to unreachable machines will be stored on the sending machine until they can be delivered. Msmq uses the terminology of "outgoing queues" for temporary storage of messages that are being delivered. If the receiving machine is down the message will sit in the "outgoing queue" until it can be delivered. If you look at the "Message Queuing" MMC plugin you will find a folder called "Outgoing Queues", this is where your published messages will show up if the subscriber is down.
IMO, the best resource for info on Msmq is John Breakwells blog:
http://blogs.msdn.com/b/johnbreakwell/archive/tags/msmq/
More info on NServiceBus combined with Msmq:
http://docs.particular.net/nservicebus/msmq/
Hope this helps!