I have publisher and subscriber implemented using nservice bus 4.4.2 version. Subscriber is not receiving the message.
I can see subscription in the publisher subscription, enabled debug trace of nservicebus and publisher log says that message is sent, but subscriber is not receiving the message.
Is there any other ways to trouble shoot the issue? The subscribe application is able to receive other subscription messages from other applications.
MSMQ is used as transport and in memory storage is used.
Any inputs are appreciated
thanks,
Kedar.
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 read the official document of Rabbitmq, it is not really clear for me what was that?
its something like Consumer Ack but with a difference that the Publisher Confirm is send by rabbitmq server to Publisher client when the server get the message from publisher client?
Can someone explain more about it?
thanks in advance.
its something like Consumer Ack but with a difference that the
Publisher Confirm is send by rabbitmq server to Publisher client when
the server get the message from publisher client?
Yes. When you enable publisher confirms, and your publisher receives acknowledgement that the message is published, you can be certain of it.
Without publisher confirms, you can lose messages in several cases. One example: your application could publish the data to the TCP buffer, but then crash, or the server itself could crash. Another example: a network device could fail mid-delivery. Another example: RabbitMQ itself could crash after receiving the TCP data containing your message.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
I am using BeginPeek() /no params/ to subscribe to messages coming in to my private queue. This is being done in a service hosted in NServiceBus host. When NServiceBus encounters transport connection timeout exception (i'm seeing circuit breaker armed logs and timeout exception logs), the peek event subscription seems get lost. When database connectivity becomes stable and new messages come in to my queue, the service is no longer notified.
Any ideas or suggestions on how to address this?
How can I log messages to a Azure Service Bus Queue and read messages from it in application.
Here you have a guide how to use queues in .net.
Focus on "How to send messages to a queue" and "How to receive messages from a queue".
The main idea of this is to create a QueueClient object using a connection string, create a BrokeredMessage and then send it to the queue.
For receiving the message, I believe that you will have a service (lets say a worker role for example) peeking messages from that queue.
There you will need to create a client and add a callback to handle the received messages. When you receive the message you can log it using Nlog.
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!