We are using NServiceBus on production, and in our log files we see the following error:
ERROR Our.Namespace.SomeMessageHandler [(null)] <(null)> - MethodName --> end with exception: NServiceBus.Unicast.Queuing.FailedToSendMessageException: Failed to send message to address: our.namespace.worker#somemachinename ---> System.Messaging.MessageQueueException: Cannot enlist the transaction.
at System.Messaging.MessageQueue.SendInternal(Object obj, MessageQueueTransaction internalTransaction, MessageQueueTransactionType transactionType)
at NServiceBus.Unicast.Queuing.Msmq.MsmqMessageSender.NServiceBus.Unicast.Queuing.ISendMessages.Send(TransportMessage message, Address address)
--- End of inner exception stack trace ---
at NServiceBus.Unicast.Queuing.Msmq.MsmqMessageSender.ThrowFailedToSendException(Address address, Exception ex)
at NServiceBus.Unicast.Queuing.Msmq.MsmqMessageSender.NServiceBus.Unicast.Queuing.ISendMessages.Send(TransportMessage message, Address address)
at NServiceBus.Unicast.UnicastBus.SendMessage(List`1 addresses, String correlationId, MessageIntentEnum messageIntent, Object[] messages)
at NServiceBus.Unicast.UnicastBus.SendMessage(Address address, String correlationId, MessageIntentEnum messageIntent, Object[] messages)
at NServiceBus.Unicast.UnicastBus.NServiceBus.IBus.Send(Address address, Object[] messages)
at Our.Namespace.SomeMessageHandler.MethodName(EventLogVO eventLog, IApplicationContext applContext, CreateEventLogHistory message)
The queue on the target machine exists (double checked). The strange thing here is that it doesn't happen all the time and for each message sent to that queue, but happens occasionally (which means that there are messages that arrive to that queue).
Searched and didn't find a similar case.
What am I missing here?
We recently had this error and tracked it down to be one of the following:
Database performance. We had a long running query that we tuned up, but the problem persisted.
Large transaction scope. You may be doing something that would cause too many resource managers to be involved.
MSMQ Resources. Ultimately our disk was not fast enough to perform the IO required for what we were doing with MSMQ.
I would try to track down the true source (hopefully you get some ideas from above). But if all else fails, first turn on the System.Transactions logging to see if it is truly a timeout. If it is, then use this section in the app.config
I had this happen to me in a handler that took over a minute to complete,
I ended up increasing the timeout by adding this to the app.config
<system.transactions>
<defaultSettings timeout="00:05:00"/>
</system.transactions>
As per this:
https://erictummers.wordpress.com/2014/05/28/cannot-enlist-the-transaction/
Additionally, I changed machine config as per this post:
http://blogs.msdn.com/b/ajit/archive/2008/06/18/override-the-system-transactions-default-timeout-of-10-minutes-in-the-code.aspx
I also wrote a quick app that edits the machine.configs:
https://github.com/hfortegcmlp/MachineConfigEditor
Related
I'm trying to create a server that sets up a Unix socket and listens for clients which send/receive data. I've made a small repository to recreate the problem.
The server runs and it can receive data from the clients that connect, but I can't get the server response to be read from the client without an error on the server.
I have commented out the offending code on the client and server. Uncomment both to recreate the problem.
When the code to respond to the client is uncommented, I get this error on the server:
thread '' panicked at 'called Result::unwrap() on an Err value: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }', src/main.rs:77:42
MRE Link
Your code calls set_read_timeout to set the timeout on the socket. Its documentation states that on Unix it results in a WouldBlock error in case of timeout, which is precisely what happens to you.
As to why your client times out, the likely reason is that the server calls stream.read_to_string(&mut response), which reads the stream until end-of-file. On the other hand, your client calls write_all() followed by flush(), and (after uncommenting the offending code) attempts to read the response. But the attempt to read the response means that the stream is not closed, so the server will wait for EOF, and you have a deadlock on your hands. Note that none of this is specific to Rust; you would have the exact same issue in C++ or Python.
To fix the issue, you need to use a protocol in your communication. A very simple protocol could consist of first sending the message size (in a fixed format, perhaps 4 bytes in length) and only then the actual message. The code that reads from the stream would do the same: first read the message size and then the message itself. Even better than inventing your own protocol would be to use an existing one, e.g. to exchange messages using serde.
I am using BizTalk Server SB-Messaging adapter to retreive messages from Azure Service Bus Queue. I have successfully managed to send message to queue myself (using same adapter), and retreive message from queue and do further processing.
Problem arises when a 3rd party software supplier is sending messages to the queue, and for BizTalk Server to retreive and process message. I then receive the following additional "header"-information and control characters in the beginning of the message:
In text: #ACKstringBShttp://schemas.microsoft.com/2003/10/Serialization/?$SOH
Seems like there is some sort of enveloped message, including headers to handle ACKnowledgement of the message to the queue.
SB-Messaging adapter gave following initial error message:
"The WCF service host at address has faulted and as a result no
more messages can be received on the corresponding receive location.
To fix the issue, BizTalk Server will automatically attempt to restart
the service host."
And, another error message:
"No Disassemble stage components can recognize the data."
Did anyone hit this problem before, and, what can be the cause of the problem? Can character encoding be a possible cause of this problem?
Here comes the feedback!
Turned out 3rd party software supplier had a setting to send message as stream, instead of string. Turns out it is a .Net application using BrokeredMessage object. Using string makes message serialized, and meta-data is added to the message. Using stream, no such serialization takes place, and message is kept untouched.
So, problem was using string and automatic serialization when sending to Service Bus Queue.
I have legacy Microsoft.ServiceBus.Messaging clients sending BrokeredMessage Xml content as <string> and I want to receive using the latest Microsoft.Azure.ServiceBus library and Message type.
Using Encoding.UTF8.GetString(message.Body) I get a unusable string prefaced with
#\u0006string\b3http://schemas.microsoft.com/2003/10/Serialization/��#
My approach is to explicitly use XmlDictionaryReader binary deserialization to undo the hidden serialization magic from the legacy library
private static string GetMessageBodyHandlingLegacyBrokeredMessage(Message message)
{
string str = null;
if (message.ContentType == null)
{
using (var reader = XmlDictionaryReader.CreateBinaryReader(
new MemoryStream(message.Body),
null,
XmlDictionaryReaderQuotas.Max))
{
var doc = new XmlDocument();
doc.Load(reader);
str = doc.InnerText;
}
}
else
throw new NotImplementedException("Unhandled Service Bus ContentType " + message.ContentType);
return str;
}
References
https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messages-payloads#payload-serialization
https://carlos.mendible.com/2016/07/17/step-by-step-net-core-azure-service-bus-and-amqp/
I have one MSMQ queue which is listened by five windows services. I used BeginPeek and PeekCompleted event for this purpose. My problem is among five services, only one service is the right recipient of the message. All four just read message, but no action is performed. This can only be identified when we read MQ message.
Now, I added a code in my services to check, if the criteria matches and the message is being processed by the right service, then I am using Receive to dequeue the message from MSMQ. Is that a good idea?
Secondly, If the message doesnot satisfy condition and all five services just peeked it, but not received, the message still lies in queue. I understand. But the same message is being processed infinite times, as the message was never removed.
private void queue_PeekCompleted(object sender, PeekCompletedEventArgs e)
{
MessageQueue queue = (MessageQueue)sender;
//Message msg = queue.EndPeek(e.AsyncResult);
Message msg = e.Message;
//Read message and check if the criteria matches
if(CriteriaMatches)
{
queue.ReceiveById(e.Message.Id);
}
queue.EndPeek(e.AsyncResult);
queue.BeginPeek();
}
Appreciate your help.
Thanks,
Fayaz
Set the messages to expire after a set (short) period. They will then move to the dead letter queue where you can have another service waiting for arrivals. This service could then raise an alert, for example, as soon as a message arrives.
I want to consume msmq service. But unable to send message to queue.
Here is my code.
System.Messaging.MessageQueue msmQ = new System.Messaging.MessageQueue("net.msmq://myServerName/private/MyQueueName");
msg ="<nodeDetails><node>Node1</node></nodeDetails>";//Dummy value. it is XML structure consist of multiple node
msmQ.Send(msg);
It gives me an error on msmQ.Send(msg)
Length cannot be less than zero. Parameter name: length
The following things are installed on my m/c:
Microsoft Message Queue(MSMQ)Server
Window Activation Process
Also when I tried as
bool msmQExits = MessageQueue.Exists("net.msmq://myServerName/private/MyQueueName");
it gives "Path syntax is invalid". I am not able to get anything on it.
I just have a msmq URL net.msmq://myServerName/private/MyQueueName.
How can I consume such URL and send my message to "MyQueueName"?
Change your queue name to this:
var queueName = #"FormatName:DIRECT=HTTP://URLAddressSpecification/net.msmq://myServerName/private/MyQueueName";
And you cannot check if a remote query exists by MessageQueue.Exists method. It will always throw an exception.
You can check these links for more info:
MSMQ FormatName
Checking if a remote query exists
Also, the problem is not with the message you see that length is less than 0. If you go deeper and check the stack trace you’ll see that your queue name has an invalid format. It tries to find FORMAT occurrence inside your queue name, doesn’t find it and Substring() method returns -1 there.
Stacktrace:
at System.String.Substring(Int32 startIndex, Int32 length)
at System.Messaging.MessageQueue.ResolveFormatNameFromQueuePath(String queuePath, Boolean throwException)
at System.Messaging.MessageQueue.get_FormatName()
at System.Messaging.MessageQueue.SendInternal(Object obj, MessageQueueTransaction internalTransaction, MessageQueueTransactionType transactionType)
at System.Messaging.MessageQueue.Send(Object obj)
at MessagingTest.Program.SendMessage(String str, Int32 x) in c:\Users\ivan.yurchenko\Documents\Visual Studio 2013\Projects\MSMQTestProjects\MessagingTest\MessagingTest\Program.cs:line 21
at MessagingTest.Program.<Main>b__1() in c:\Users\ivan.yurchenko\Documents\Visual Studio 2013\Projects\MSMQTestProjects\MessagingTest\MessagingTest\Program.cs:line 38
at System.Threading.Tasks.Task.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
Here is an example for how to consume the service.
It has Wcf Service,Physical MSMQ, and the client project. So you have to have a WCF service to receive the message and msmq to store the message and a client to send the message.
http://www.codeproject.com/Articles/326909/Creating-a-WCF-Service-with-MSMQ-Communication-and
Occasionally when NServiceBus picks up a message, it fails with the exception below. This causes NServiceBus to retry (up to it's configured retry limit). Sometimes one of the retries result in the message being handled successfully, but it's common for all retries to fail with the same exception. In this case, the message is routed to the error queue as expected when all retries fail.
My question is... what would cause this exception in the first place? It doesn't appear related to my message handler code, as my code doesn't appear in the stack trace.
NServiceBus version: 2.6.0.1504
OS: Windows Server 2003
Handler code is targeting .NET 3.5 or earlier
Here is the full exception message and stack trace:
NServiceBus.Unicast.Transport.Msmq.MsmqTransport [(null)] - Failed raising 'finished message processing' event. System.Messaging.MessageQueueException: Cannot enlist the transaction.
at System.Messaging.MessageQueue.SendInternal(Object obj, MessageQueueTransaction internalTransaction, MessageQueueTransactionType transactionType)
at System.Messaging.MessageQueue.Send(Object obj, MessageQueueTransactionType transactionType)
at NServiceBus.Unicast.Transport.Msmq.MsmqTransport.SendMsmqMessage(Message m, String destination)
at NServiceBus.Unicast.Transport.Msmq.MsmqTransport.Send(TransportMessage m, String destination)
at NServiceBus.Unicast.UnicastBus.SendReadyMessage(Boolean startup)
at NServiceBus.Unicast.UnicastBus.TransportFinishedMessageProcessing(Object sender, EventArgs e)
at NServiceBus.Unicast.Transport.Msmq.MsmqTransport.OnFinishedMessageProcessing()
I see the method NServiceBus.Unicast.UnicastBus.SendReadyMessage(Boolean startup) in your stack trace.
This tells me that your endpoint is connected to a Distributor. After all your message handlers have completed, an endpoint connected to a distributor will send the ReadyMessage back to the Distributor's control queue to say "I'm done with that work. Please send more!"
This is supposed to happen within the same transaction as the rest of your work, but apparently the MSMQ send is having trouble enlisting in that transaction. This could point to a problem with DTC. It would be interesting to know what else you have going on in your message handlers for that message type that also enlist in the transaction. You aren't manually committing or rolling anything back are you?