I'm working on a BizTalk application that sends messages to a Transactional MSMQ location. If it is unable to write to the Queue, the message gets sent to the Dead Letter Queue on the BizTalk server. Is there a better way to handle this? I would prefer the message to suspend so we would get notification from BizTalk360. If it is not possible to suspend the message, and the message must go to the Dead Letter Queue, how can I recover the message once the issue that prevented writing to the Queue is corrected?
Ok, so the best way that I have found to accomplish this is a bit of a hack in my opinion, but it works. I am setting up a receive port/location listening to the Dead Letter Queue at DIRECT=.\SYSTEM$;DEADXACT. I also added an orchestration that listens for messages coming from that receive port and immediately throws an exception suspending the message allowing BizTalk360 to send me notification that there is an issue.
Related
Is there any way to configure an MSMQ queue to send copies of all messages it receives to another MSMQ queue? I have a memory leak on a production application that services a queue. I have a test version (that hopefully fixes the memory leak) on a test server, that services a test queue. I want to deluge the test version with the production stream of messages, to ensure that the memory leak has been fixed. After I am done testing, I would like to shut off this "message forwarding"
I had the same problem on my application, I was faced with 2 solutions, the easiest one I would recommend you to do is to make a very simple application that Peeks every message in a Queue via a transaction, and send a copy of the Message object to another queue, and you're done, just Abort() the transaction, that way you can be sure it'll be restored and wait for the production app to process the messages.
The other alternative would be to have the Message Queue apps just send the messages to yet another message queue, that way you don't have to mess around with peeks in Production and you'll have full access to your own queue in a test environment.
No. MSMQ is a protocol for delivering messages. You would need an application to read the delivered messages and send new copies to a different queue.
I use NServiceBus with MSMQ on Windows Server 2008.
In one of our scenario we send a command to another server queue but sometimes the message never arrives in the queue and MSQM doesn't throw an exception.
I have written a small application that sends a message directly to the queue without NServiceBus and I have encountered the same problem.
I think it isn't a nservicebus problem but a MSMQ problem : windows security, network,...
How can I force MSMQ to return an error when the message can't be saved in queue ?
What are the possible reasons of this behavior ?
Where are the messages that have disappeared ?
In the MSMQ Management snap-in take a look at the system queues and look at transactional dead letter and non-transactional dead letter queues.
Also be sure to have setup queue ACL correctly.
Windows Server 2012
MSMQ 6 Workgroup Mode
We've had issues trying to recover MSMQ messages that were sent to the transaction dead letter queue. We've tried moving them to the outbound queue, the message seems to send fine (even the Event Log says so) however it never gets to the destination queue.
After trial and error we've figured out how to get them to another queue on the same server but not to the destination queue on a remote server. We don't want to lose anymore messages. Does anyone have any suggestion on how we can deliver these messages?
Thank you,
David
As I understood your question, it's a one time problem with some number of messages you already have in MSMQ, and not general connectivity issue between machines? If so, you should be able to solve it with some MSMQ management tool. Disclaimer: I'm the author of one such tool - QueueExplorer. I don't know what other tools can do, but with QueueExplorer you can copy/paste or drag/drop messages to another machine opened in separate tab/window. In order to do that QueueExplorer has to perform MSMQ Send operation, so messages will have to pass through MSMQ between these two machines.
So if there's still that issue that prevented original delivery you'll still be stuck. In that case you can save all messages to a file, transfer it to another machine through file system and load it there to whichever queue they should go. This is obviusly just a manual workaround for one time situation. Btw. this could be done in QueueExplore's trial mode.
If however problem is with connectivity and messages always end up in dead letter queue, it's better to check them from Computer Management. It's one area where it's better than our tool - you can turn on "Class" column and see reason why messages couldn't be delivered. For instance if you see "The time-to-be-received has elapsed" you'll know what's the problem.
I have a transactional private message queue (among other message queues on which I have not seen this problem) on a Windows Server 2008 R2 server.
This particular queue has a recurring problem happening every few weeks where the console shows a nonzero count of messages in the queue, but it does not have any messages in the queue itself or any subqueue. Queue Explorer shows the same thing. Performance counters indicate there are messages like the count in the built-in msmq console and queue explorer.
I cannot find any messages. I understand that I could see a situation like this for outgoing queues with dead letter tracking such that it may have been delivered to a remote machine but not yet processed. This is not an outgoing queue, though. Messages are sourced from remote machines and have landed here on this machine.
Also, I am certain that the count I'm seeing are not journal messages or subqueues.
Does this make any sense? Is there a logical explanation for this and under some circumstance this is expected? If so, what is it?
EDIT: Removed info about purging queue removing the count - that was incorrect. Purging actually does nothing and leaves me in the same state as before with a count reflected, but no messages showing.
As you noted, you can see a message count on an outgoing queue if source journaling is in use. The invisible messages are there in case they need to be moved to the DLQ.I would expect your problem to be similar - there should be a visible message in the outgoing queue and an invisible message in the destination queue because delivery hasn't completed. I assume a handshaking or storage acknowledgement has been lost along the way. Or maybe the message has been processed and removed from the queue but MSMQ couldn't update the sender of the fact. Check the outgoing queues on the remote machines sending TO this queue.
So, I am new to MSMQ and NServiceBus. I played around with demos and got a working scenario going with NServiceBus. (Getting my own up and running was even easier than following the demo thanks to the new Modeling tools!)
I then went and presented my plan (based off my work with the demo and my own model) to my co-workers. Two of them were versed in using MSMQ and started asking me questions about how I will handle "Dead Letters".
I had never heard of "Dead Letters". They explained that it is queue used for messages that things cannot be sent (either because the other end refuses them or if the other end is not there).
The concern of my co-workers is that if we don't have Dead Letter queues then how will we stop a message from blocking the queue? (If the queue is FIFO and the top message can't be sent, then it blocks the other messages behind it right?)
On the other hand, if we have "Dead Letter" queues how are they managed? (Do I get an event from NServiceBus that tells me a new message is in the Dead Letter queue? How do I configure when a message will go to the Dead Letter queue? How can I try to re-send a Dead Letter message?)
So basically, how does NServiceBus deal with undeliverable messages?
Typically, you specify an error queue as well, which is where messages that couldn't be sent will go. Look at their MSMQ example:
http://docs.particular.net/nservicebus/msmq/transportconfig &
http://docs.particular.net/nservicebus/msmq/connection-strings
<MsmqTransportConfig InputQueue="MyClient" ErrorQueue="error"
NumberOfWorkerThreads="1" MaxRetries="5"/>
In this scenario, the error queue will reside on the same machine as the input queue. This may also be a remote queue, if preferred. MaxRetries refers to the number of attempts to send before it gets put into the error queue. How you choose to handle the error queue is up to you, however.