Discussion:
MSMQ very occasionally losing messages?
(too old to reply)
delard
2007-02-01 16:15:02 UTC
Permalink
Hi,

We develop an application which has been using MSMQ for some time
successfully. However recently I’ve noticed some problems with messages
getting ‘lost’.

Originally I noticed this problem when some clients started losing about 70%
of all messages. This behaviour was very rare – and a reboot of the client
seemed to fix it. It could be that this behaviour was caused by a client
specific setup problem? However – more seriously - because of that issue I
started systematically testing MSMQ end-end connectivity from each client –
and this showed that very occasionally (maybe 1 in 1500) a message is getting
lost on all the clients!

When I say ‘lost’, I mean that the application calls the Send without any
errors – but there is no sign of the message on the source or destination
machines that I can see (though I’m far from an MQ expert).

The setup is a central Windows 2003 x64 server, with a variety of clients we
use for testing (note – all the clients seem to suffer from the ‘very
occasional loss’ problem) :
- clients running Windows server 2003 (32bit) in Workstation mode
- clients running XP Pro x64 in Domain mode
- clients running Windows XP Pro SP2, both 32bit and x64).in both Domain and
Workstation modes.

I’m using Visual Studio .NET 2003 to create the application – which is
running as a simple console app – written in C#. Its using the
System.Messaging MessageQueue class (.NET Framework 1.1). The queues are
setup as non-transactional, without journaling, and with full permissions for
‘Everyone’ and ‘Anonymous User’.

Here is a small test program which reproduces the problem. This just opens a
remote private queue, sends a message to it, then tries to receive that
message. It’s the only thing using that queue – but after a while (avg 1.5k
iterations) a message gets lost and it times out waiting to receive it. Note
– adding a pause between the send and receive doesn’t prevent this problem –
and I’ve left that out so it runs much faster.

using System;
using System.Threading;
using System.Messaging;

namespace TestMQ
{
class Class1
{
// Small test program to loop endlessly - sending a message via MSMQ and
testing it can be received
static void Main(string[] args)
{
int attemptcount = 0;
int failurecount = 0;

while(true)
{
Console.WriteLine("Starting attempt " + attemptcount++ + ". " +
failurecount + " problems so far...");

// Open the queue. Its a private queue on Windows 2003 x64 server
MessageQueue queue = new
MessageQueue(@"FormatName:DIRECT=OS:theserver\private$\heartbeatclientqueue");

queue.Formatter = new BinaryMessageFormatter();

queue.Purge(); // just in case there was anything already on queue...

// Create a message...
string messagebody = "TestMessageBody";
Message m = new Message(messagebody, new BinaryMessageFormatter());
m.Label = "TestMessageLabel";

// set some attributes on message... I've no idea if these make any
difference - I've set them in attempt to stop lost messages
m.Recoverable = true;
m.UseDeadLetterQueue = true;
m.UseAuthentication = false;
m.AcknowledgeType = AcknowledgeTypes.NotAcknowledgeReachQueue;

// send message - then close queue (google told me I had to do it!).
queue.Send(m);
queue.Close();

// Try to get the message back from the queue - give it 2 whole
minutes to be very generous!
Message received = null;
try
{
received = queue.Receive(TimeSpan.FromMinutes(2.0));
queue.Close();
}
catch (Exception e)
{
Console.WriteLine("Exception from MSMQ receive : " + e.Message);
}

if (received == null || (string)received.Body != messagebody)
Console.WriteLine("Message lost on attempt " + failurecount++);
}
}
}
}

I guess there must be something wrong with one of :

1) my MQ client setup. I installed the full MQ client options.
2) my MQ server setup or queue setup on the server
3) the code I’m using to use the queue – maybe I’m missing some flags etc?
4) the network – though everything else is fine here

Any advice on how to avoid this problem would be greatly appreciated.

Thanks - Delard
John Breakwell (MSFT)
2007-02-01 17:53:43 UTC
Permalink
Hi

You need to be able to distinguish between message failed to arrive and
message failed to be received.
For tests like this it is always useful to run Perfmon on sender and
receiver.
You can then easily comparing "MSMQ Service/Outgoing Messages" on the sender
with "MSMQ Service/Incoming Messages" on the receiver.
As these are running totals (and not rates) the numbers should be exactly
the same if delivery was successful.
Delivery does not necessarily mean it is put in the queue (MSMQ may reject
it) so also monitor "MSMQ Queue/Messages in Queue/heartbeatclientqueue".
As you have a 2-minute interval, perfmon should show a clear rise and fall
in the queue total during normal operation.

You have set UseDeadLetterQueue = true and AcknowledgeType =
AcknowledgeTypes.NotAcknowledgeReachQueue.
These are useful if you cannot deliver messages - is anything in the
sender's DLQ?

Journaling should be enabled on both ends for test too so you can easily
demonstrate departure and arrival happened.

Do you get the same problem using transactional messaging?
If you don't use transactional messaging then you are not guaranteed
reliability for delivery.
You are performing Remote Read which uses RPC and is non-transactional
(except in Vista where it now can be transactional).
So reliability is not guaranteed there either.

Cheers
John Breakwell
Post by delard
Hi,
We develop an application which has been using MSMQ for some time
successfully. However recently I've noticed some problems with messages
getting 'lost'.
Originally I noticed this problem when some clients started losing about 70%
of all messages. This behaviour was very rare - and a reboot of the client
seemed to fix it. It could be that this behaviour was caused by a client
specific setup problem? However - more seriously - because of that issue I
started systematically testing MSMQ end-end connectivity from each
client -
and this showed that very occasionally (maybe 1 in 1500) a message is getting
lost on all the clients!
When I say 'lost', I mean that the application calls the Send without any
errors - but there is no sign of the message on the source or destination
machines that I can see (though I'm far from an MQ expert).
The setup is a central Windows 2003 x64 server, with a variety of clients we
use for testing (note - all the clients seem to suffer from the 'very
- clients running Windows server 2003 (32bit) in Workstation mode
- clients running XP Pro x64 in Domain mode
- clients running Windows XP Pro SP2, both 32bit and x64).in both Domain
and
Workstation modes.
I'm using Visual Studio .NET 2003 to create the application - which is
running as a simple console app - written in C#. Its using the
System.Messaging MessageQueue class (.NET Framework 1.1). The queues are
setup as non-transactional, without journaling, and with full permissions for
'Everyone' and 'Anonymous User'.
Here is a small test program which reproduces the problem. This just opens a
remote private queue, sends a message to it, then tries to receive that
message. It's the only thing using that queue - but after a while (avg
1.5k
iterations) a message gets lost and it times out waiting to receive it. Note
- adding a pause between the send and receive doesn't prevent this
problem -
and I've left that out so it runs much faster.
using System;
using System.Threading;
using System.Messaging;
namespace TestMQ
{
class Class1
{
// Small test program to loop endlessly - sending a message via MSMQ and
testing it can be received
static void Main(string[] args)
{
int attemptcount = 0;
int failurecount = 0;
while(true)
{
Console.WriteLine("Starting attempt " + attemptcount++ + ". " +
failurecount + " problems so far...");
// Open the queue. Its a private queue on Windows 2003 x64 server
MessageQueue queue = new
queue.Formatter = new BinaryMessageFormatter();
queue.Purge(); // just in case there was anything already on queue...
// Create a message...
string messagebody = "TestMessageBody";
Message m = new Message(messagebody, new BinaryMessageFormatter());
m.Label = "TestMessageLabel";
// set some attributes on message... I've no idea if these make any
difference - I've set them in attempt to stop lost messages
m.Recoverable = true;
m.UseDeadLetterQueue = true;
m.UseAuthentication = false;
m.AcknowledgeType = AcknowledgeTypes.NotAcknowledgeReachQueue;
// send message - then close queue (google told me I had to do it!).
queue.Send(m);
queue.Close();
// Try to get the message back from the queue - give it 2 whole
minutes to be very generous!
Message received = null;
try
{
received = queue.Receive(TimeSpan.FromMinutes(2.0));
queue.Close();
}
catch (Exception e)
{
Console.WriteLine("Exception from MSMQ receive : " + e.Message);
}
if (received == null || (string)received.Body != messagebody)
Console.WriteLine("Message lost on attempt " + failurecount++);
}
}
}
}
1) my MQ client setup. I installed the full MQ client options.
2) my MQ server setup or queue setup on the server
3) the code I'm using to use the queue - maybe I'm missing some flags etc?
4) the network - though everything else is fine here
Any advice on how to avoid this problem would be greatly appreciated.
Thanks - Delard
delard
2007-02-07 16:31:01 UTC
Permalink
Hi,

Thanks for your help. I now think the problem may be caused by sending
messages immediately after a purge of the queue. If I don't do the purge the
problem doesn't seem to happen...

It seems like the call to Purge returns before the purge is complete on the
server - therefore sometimes the message sent immediately afterwards is
removed by the purge? If this is the case then its good news - I can easily
avoid the problem by making sure theres a sensible delay between purge and
send.

Can you confirm this is correct?

thanks - Delard
Post by John Breakwell (MSFT)
Hi
You need to be able to distinguish between message failed to arrive and
message failed to be received.
For tests like this it is always useful to run Perfmon on sender and
receiver.
You can then easily comparing "MSMQ Service/Outgoing Messages" on the sender
with "MSMQ Service/Incoming Messages" on the receiver.
As these are running totals (and not rates) the numbers should be exactly
the same if delivery was successful.
Delivery does not necessarily mean it is put in the queue (MSMQ may reject
it) so also monitor "MSMQ Queue/Messages in Queue/heartbeatclientqueue".
As you have a 2-minute interval, perfmon should show a clear rise and fall
in the queue total during normal operation.
You have set UseDeadLetterQueue = true and AcknowledgeType =
AcknowledgeTypes.NotAcknowledgeReachQueue.
These are useful if you cannot deliver messages - is anything in the
sender's DLQ?
Journaling should be enabled on both ends for test too so you can easily
demonstrate departure and arrival happened.
Do you get the same problem using transactional messaging?
If you don't use transactional messaging then you are not guaranteed
reliability for delivery.
You are performing Remote Read which uses RPC and is non-transactional
(except in Vista where it now can be transactional).
So reliability is not guaranteed there either.
Cheers
John Breakwell
Post by delard
Hi,
We develop an application which has been using MSMQ for some time
successfully. However recently I've noticed some problems with messages
getting 'lost'.
Originally I noticed this problem when some clients started losing about 70%
of all messages. This behaviour was very rare - and a reboot of the client
seemed to fix it. It could be that this behaviour was caused by a client
specific setup problem? However - more seriously - because of that issue I
started systematically testing MSMQ end-end connectivity from each
client -
and this showed that very occasionally (maybe 1 in 1500) a message is getting
lost on all the clients!
When I say 'lost', I mean that the application calls the Send without any
errors - but there is no sign of the message on the source or destination
machines that I can see (though I'm far from an MQ expert).
The setup is a central Windows 2003 x64 server, with a variety of clients we
use for testing (note - all the clients seem to suffer from the 'very
- clients running Windows server 2003 (32bit) in Workstation mode
- clients running XP Pro x64 in Domain mode
- clients running Windows XP Pro SP2, both 32bit and x64).in both Domain
and
Workstation modes.
I'm using Visual Studio .NET 2003 to create the application - which is
running as a simple console app - written in C#. Its using the
System.Messaging MessageQueue class (.NET Framework 1.1). The queues are
setup as non-transactional, without journaling, and with full permissions for
'Everyone' and 'Anonymous User'.
Here is a small test program which reproduces the problem. This just opens a
remote private queue, sends a message to it, then tries to receive that
message. It's the only thing using that queue - but after a while (avg
1.5k
iterations) a message gets lost and it times out waiting to receive it. Note
- adding a pause between the send and receive doesn't prevent this
problem -
and I've left that out so it runs much faster.
using System;
using System.Threading;
using System.Messaging;
namespace TestMQ
{
class Class1
{
// Small test program to loop endlessly - sending a message via MSMQ and
testing it can be received
static void Main(string[] args)
{
int attemptcount = 0;
int failurecount = 0;
while(true)
{
Console.WriteLine("Starting attempt " + attemptcount++ + ". " +
failurecount + " problems so far...");
// Open the queue. Its a private queue on Windows 2003 x64 server
MessageQueue queue = new
queue.Formatter = new BinaryMessageFormatter();
queue.Purge(); // just in case there was anything already on queue...
// Create a message...
string messagebody = "TestMessageBody";
Message m = new Message(messagebody, new BinaryMessageFormatter());
m.Label = "TestMessageLabel";
// set some attributes on message... I've no idea if these make any
difference - I've set them in attempt to stop lost messages
m.Recoverable = true;
m.UseDeadLetterQueue = true;
m.UseAuthentication = false;
m.AcknowledgeType = AcknowledgeTypes.NotAcknowledgeReachQueue;
// send message - then close queue (google told me I had to do it!).
queue.Send(m);
queue.Close();
// Try to get the message back from the queue - give it 2 whole
minutes to be very generous!
Message received = null;
try
{
received = queue.Receive(TimeSpan.FromMinutes(2.0));
queue.Close();
}
catch (Exception e)
{
Console.WriteLine("Exception from MSMQ receive : " + e.Message);
}
if (received == null || (string)received.Body != messagebody)
Console.WriteLine("Message lost on attempt " + failurecount++);
}
}
}
}
1) my MQ client setup. I installed the full MQ client options.
2) my MQ server setup or queue setup on the server
3) the code I'm using to use the queue - maybe I'm missing some flags etc?
4) the network - though everything else is fine here
Any advice on how to avoid this problem would be greatly appreciated.
Thanks - Delard
John Breakwell (MSFT)
2007-02-08 20:54:59 UTC
Permalink
Hi, yes MSMQ will handle requests like Purge when it has the time.
Your application (or the MMC, whichever) will have a Success response as the
request was successfully submitted.
The Purge will go into a queue {no relation} and, when it gets to the front,
MSMQ will process it.
As a rule of thumb, if you assume that everything in MSMQ is asynchronous
then you won't be disappointed.

Cheers
John Breakwell
Post by delard
Hi,
It seems like the call to Purge returns before the purge is complete on the
server - therefore sometimes the message sent immediately afterwards is
removed by the purge? If this is the case then its good news - I can easily
avoid the problem by making sure theres a sensible delay between purge and
send.
Can you confirm this is correct?
thanks - Delard
raind
2007-03-28 08:54:00 UTC
Permalink
I encountered the same problem, even if use asynchronous mode to receive the
message, some message may be lost when the message send frequently.

someone can help me to solve it?
Post by John Breakwell (MSFT)
Hi, yes MSMQ will handle requests like Purge when it has the time.
Your application (or the MMC, whichever) will have a Success response as the
request was successfully submitted.
The Purge will go into a queue {no relation} and, when it gets to the front,
MSMQ will process it.
As a rule of thumb, if you assume that everything in MSMQ is asynchronous
then you won't be disappointed.
Cheers
John Breakwell
Post by delard
Hi,
It seems like the call to Purge returns before the purge is complete on the
server - therefore sometimes the message sent immediately afterwards is
removed by the purge? If this is the case then its good news - I can easily
avoid the problem by making sure theres a sensible delay between purge and
send.
Can you confirm this is correct?
thanks - Delard
John Breakwell (MSFT)
2007-03-28 10:01:33 UTC
Permalink
Hi,

Sure, we can try to help you solve it.
What are you actually trying to do?
Are you receiving from a local or remote queue?
Express, recoverable or transactional messages?
How often is "frequently"?
How do you determine that a message is lost? Do you get an error message?

Cheers
John Breakwell
Post by raind
I encountered the same problem, even if use asynchronous mode to receive the
message, some message may be lost when the message send frequently.
someone can help me to solve it?
Post by John Breakwell (MSFT)
Hi, yes MSMQ will handle requests like Purge when it has the time.
Your application (or the MMC, whichever) will have a Success response as the
request was successfully submitted.
The Purge will go into a queue {no relation} and, when it gets to the front,
MSMQ will process it.
As a rule of thumb, if you assume that everything in MSMQ is asynchronous
then you won't be disappointed.
Cheers
John Breakwell
Post by delard
Hi,
It seems like the call to Purge returns before the purge is complete on the
server - therefore sometimes the message sent immediately afterwards is
removed by the purge? If this is the case then its good news - I can easily
avoid the problem by making sure theres a sensible delay between purge and
send.
Can you confirm this is correct?
thanks - Delard
raind
2007-03-29 03:08:03 UTC
Permalink
Let me describe our scenario.

We need communication via MSMQ between MachineA and MachineB by following
steps:
1. ApplicationA(on MachineA) send a request message to the queueB at MachineB.
2. ApplicationB(on MachineB) receive the request message from local queue,
then send a response message or a

sequence of messages(with a short pause after a message sent) to the queueA
at MachineA.
3. ApplicationA receive the response message from local queue(queueA).

In the case of single response message, it always works properly.
But we found in the case of multiple response messages return, some messages
in the sequence maybe omitted

occasionally at step3. Which piece of message be omitted is at random, and
no exception can be catch during the

process.

I can confirm all the messages send from ApplicationB reached queueA by the
MSMQ Journal, so the problem is why

some messages would be lost when receiving.(at step3)
Post by John Breakwell (MSFT)
Are you receiving from a local or remote queue?
Receiving from local and sending to remote.
Post by John Breakwell (MSFT)
Express, recoverable or transactional messages?
Express messages and never tried other type.
Post by John Breakwell (MSFT)
How often is "frequently"?
The pause time between each response message sending about 1 second(maybe
the frequnce is not related to this problem).
Post by John Breakwell (MSFT)
How do you determine that a message is lost? Do you get an error message?
All response message send from ApplicationB is XML fromat and have a field
"ID", the ID is unique. At step2, when ApplicationB answer three
messages(with ID 1,2 and 3), sometimes ApplicationA can receive all of them,
and sometimes only received message ID1 and message ID2, or message ID2 and
message ID3,the issue properbility about 30%.

The following is the code for message receiving of ApplicationA, I trace it
and found sometimes the MessageQueue_ReceiveCompleted method only be called
twice even if three new message add to the Jounal of queueA.

no exception, no error message, seems the message disappeared in air.


private void BeginAsyncReceive()
{
try
{
Msmq.ReceiveCompleted += new
ReceiveCompletedEventHandler(MessageQueue_ReceiveCompleted);

threadForAsyncReceive = new Thread(new
ThreadStart(this.AsyncReceivingThreadStartPoint));
threadForAsyncReceive.Start();

isInAsyncReceiving = true;
}
catch (MessageQueueException e)
{
Log.WriteLogItem(LogLevel.Error, e.ErrorCode,e.Message);
}
}

private void AsyncReceivingThreadStartPoint()
{
try
{
this.waitHandle =
base.Msmq.BeginReceive(MessageQueue.InfiniteTimeout).AsyncWaitHandle;
this.waitHandle.WaitOne();
}
catch (Exception e)
{
Log.WriteLogItem(LogLevel.Warring,ErrorCode.MessageQueueError,e.Message);
}
}

private void MessageQueue_ReceiveCompleted(object sender,
ReceiveCompletedEventArgs e)
{
try
{
MessageQueue mq = (MessageQueue)sender;
Message m = mq.EndReceive(e.AsyncResult);

//trigger a event to up level ....

}
catch (MessageQueueException ex)
{
Log.WriteLogItem(LogLevel.Warring, ErrorCode.MessageQueueError,
ex.Message);
}
catch (Exception ex1)
{
Log.WriteLogItem(LogLevel.Warring, ErrorCode.Unknown, ex1.Message);
}
finally
{
this.waitHandle =
base.Msmq.BeginReceive(MessageQueue.InfiniteTimeout).AsyncWaitHandle;
}
}



Any idea? Thank you in advance.
Post by John Breakwell (MSFT)
Hi,
Sure, we can try to help you solve it.
What are you actually trying to do?
Are you receiving from a local or remote queue?
Express, recoverable or transactional messages?
How often is "frequently"?
How do you determine that a message is lost? Do you get an error message?
Cheers
John Breakwell
Post by raind
I encountered the same problem, even if use asynchronous mode to receive the
message, some message may be lost when the message send frequently.
someone can help me to solve it?
Post by John Breakwell (MSFT)
Hi, yes MSMQ will handle requests like Purge when it has the time.
Your application (or the MMC, whichever) will have a Success response as the
request was successfully submitted.
The Purge will go into a queue {no relation} and, when it gets to the front,
MSMQ will process it.
As a rule of thumb, if you assume that everything in MSMQ is asynchronous
then you won't be disappointed.
Cheers
John Breakwell
Post by delard
Hi,
It seems like the call to Purge returns before the purge is complete on the
server - therefore sometimes the message sent immediately afterwards is
removed by the purge? If this is the case then its good news - I can easily
avoid the problem by making sure theres a sensible delay between purge and
send.
Can you confirm this is correct?
thanks - Delard
John Breakwell (MSFT)
2007-03-29 10:56:54 UTC
Permalink
OK,

Response messages
- Is keeping the sequence order important?
- As you are using Express messages, you can't guarantee in-order delivery.
You need transactional messages for that.
- Why is there a delay between sending response messages?

Journalling
- Which journaling have you enabled?
~ Source journaling (to log when messages are sent successfully)
~ Target journaling (to log when messages are read from the queue)
It sounds like you are using Target journaling as you mention "Jounal of
queueA."

I'm not good at the code side of things but if there are 3 copies of
messages in the target journal queue then 3 messages were read.
MSMQ will only put the messages in the journal when an application reads
them.
Hopefully someone else can comment on your code.

Cheers
John Breakwell
raind
2007-03-29 12:58:01 UTC
Permalink
John Breakwell, thank you for your reply.

The message's order is inessential, it's ok just all messages be received.
but I'm wondering that the Queue is FIFO, why can't guarantee in-order
delivery?

The pause between each message sending is not necessary too, I ever consider
that the message lost is cause by the message sending too fast, so add a
delay artificially.

The Journal I said is point to the Target journaling, but I think the target
journaling will record it as soon as the message reaches the target mq, not
care it was readed or not. Because even if I closed ApplicationA, the new
message still appears in the Jounal. Is it true?
Post by John Breakwell (MSFT)
OK,
Response messages
- Is keeping the sequence order important?
- As you are using Express messages, you can't guarantee in-order delivery.
You need transactional messages for that.
- Why is there a delay between sending response messages?
Journalling
- Which journaling have you enabled?
~ Source journaling (to log when messages are sent successfully)
~ Target journaling (to log when messages are read from the queue)
It sounds like you are using Target journaling as you mention "Jounal of
queueA."
I'm not good at the code side of things but if there are 3 copies of
messages in the target journal queue then 3 messages were read.
MSMQ will only put the messages in the journal when an application reads
them.
Hopefully someone else can comment on your code.
Cheers
John Breakwell
John Breakwell (MSFT)
2007-03-29 13:49:06 UTC
Permalink
Hi

I don't know too much about the guts of MSMQ but my understanding is that it
is not a serial operation for messages to be transferred from the network
card's data buffer to the message queue.
So it is possible (though very unlilkely) for a message to get through the
system fractionally faster than the message that arrived before it.
This scenario also happens if you are sending messages across a complicated
network - messages can take different routes based on what the routers
decide to do.
Therefore, because messages can theoretically arrive out of order nobody
should design an application that depends on them arriving in order unless
they use transactional queues (as these come with a guarantee).

Message arrive rate should not be a problem.
You can get some performance issues when you REALLY load the server - 1,000s
of clients, lots of messages - but they normally can be resolved with
tuning.

Target journaling - http://msdn2.microsoft.com/en-us/library/ms706956.aspx
"Message Queuing places a copy of any message that you retrieve from the
queue"
"This does not include messages removed from the queue when their
time-to-be-received timer expires, or messages purged from the queue."

If you sent 3 messages to the queue while the application that read from the
queue was OFF then nothing will appear in the target journal queue.
When you start the application and the messages are read, then 3 messages
should appear in the target journal queue.

Cheers
John Breakwell
Post by raind
John Breakwell, thank you for your reply.
The message's order is inessential, it's ok just all messages be received.
but I'm wondering that the Queue is FIFO, why can't guarantee in-order
delivery?
The pause between each message sending is not necessary too, I ever consider
that the message lost is cause by the message sending too fast, so add a
delay artificially.
The Journal I said is point to the Target journaling, but I think the target
journaling will record it as soon as the message reaches the target mq, not
care it was readed or not. Because even if I closed ApplicationA, the new
message still appears in the Jounal. Is it true?
Post by John Breakwell (MSFT)
OK,
Response messages
- Is keeping the sequence order important?
- As you are using Express messages, you can't guarantee in-order delivery.
You need transactional messages for that.
- Why is there a delay between sending response messages?
Journalling
- Which journaling have you enabled?
~ Source journaling (to log when messages are sent successfully)
~ Target journaling (to log when messages are read from the queue)
It sounds like you are using Target journaling as you mention "Jounal of
queueA."
I'm not good at the code side of things but if there are 3 copies of
messages in the target journal queue then 3 messages were read.
MSMQ will only put the messages in the journal when an application reads
them.
Hopefully someone else can comment on your code.
Cheers
John Breakwell
raind
2007-03-30 04:04:05 UTC
Permalink
Yes, it's my misunderstanding about MSMQ Journaling,
But based on new understanding, I wondering more why the Journaling
recorded three messages but the MessageQueue_ReceiveCompleted message only be
called twice occasionally, could it is a .net framework bug?
Is there anyway to avoid it?

but the issue still not be solved.
Post by John Breakwell (MSFT)
Hi
I don't know too much about the guts of MSMQ but my understanding is that it
is not a serial operation for messages to be transferred from the network
card's data buffer to the message queue.
So it is possible (though very unlilkely) for a message to get through the
system fractionally faster than the message that arrived before it.
This scenario also happens if you are sending messages across a complicated
network - messages can take different routes based on what the routers
decide to do.
Therefore, because messages can theoretically arrive out of order nobody
should design an application that depends on them arriving in order unless
they use transactional queues (as these come with a guarantee).
Message arrive rate should not be a problem.
You can get some performance issues when you REALLY load the server - 1,000s
of clients, lots of messages - but they normally can be resolved with
tuning.
Target journaling - http://msdn2.microsoft.com/en-us/library/ms706956.aspx
"Message Queuing places a copy of any message that you retrieve from the
queue"
"This does not include messages removed from the queue when their
time-to-be-received timer expires, or messages purged from the queue."
If you sent 3 messages to the queue while the application that read from the
queue was OFF then nothing will appear in the target journal queue.
When you start the application and the messages are read, then 3 messages
should appear in the target journal queue.
Cheers
John Breakwell
Post by raind
John Breakwell, thank you for your reply.
The message's order is inessential, it's ok just all messages be received.
but I'm wondering that the Queue is FIFO, why can't guarantee in-order
delivery?
The pause between each message sending is not necessary too, I ever consider
that the message lost is cause by the message sending too fast, so add a
delay artificially.
The Journal I said is point to the Target journaling, but I think the target
journaling will record it as soon as the message reaches the target mq, not
care it was readed or not. Because even if I closed ApplicationA, the new
message still appears in the Jounal. Is it true?
Post by John Breakwell (MSFT)
OK,
Response messages
- Is keeping the sequence order important?
- As you are using Express messages, you can't guarantee in-order delivery.
You need transactional messages for that.
- Why is there a delay between sending response messages?
Journalling
- Which journaling have you enabled?
~ Source journaling (to log when messages are sent successfully)
~ Target journaling (to log when messages are read from the queue)
It sounds like you are using Target journaling as you mention "Jounal of
queueA."
I'm not good at the code side of things but if there are 3 copies of
messages in the target journal queue then 3 messages were read.
MSMQ will only put the messages in the journal when an application reads
them.
Hopefully someone else can comment on your code.
Cheers
John Breakwell
Loading...