[rabbitmq-discuss] Migrating from MSMQ:Identifying queue features
mabra at manfbraun.de
mabra at manfbraun.de
Tue Jan 8 18:59:05 GMT 2013
Thank you very much; I'll try to go in now.
> -----Original Message-----
> From: Emile Joubert [mailto:emile at rabbitmq.com]
> Sent: Thursday, January 03, 2013 2:53 PM
> To: Discussions about RabbitMQ
> Cc: mabra
> Subject: Re: [rabbitmq-discuss] Migrating from MSMQ:Identifying queue
> On 02/01/13 16:59, mabra wrote:
> > I have several apps A, which generates messages with expiration time
> > of about 2 hours. I have several apps B, which evals these Messages.
> > They are sometimes running, sometimes not.
> It is possible to define per-queue or per-message timeouts:
> > Usually the B type is running permanently and in normal operation, it
> > reads each message, but does this by peek-ing the the queue and leave
> > them in the queue.
> It is possible to dequeue and requeue a message, which is similar to
> peeking at the head of the queue. Bear in mind that repeating this
> operation in the absence of other consumers will lead to the same
> message being observed.
> For rejecting using the .net client see
> Using rejection of messages to implement message selection in consumers
> is not recommended. If different consumers (app B) process different
> messages then you are advised to route message based on that difference
> so that consumers only ever observe messages that they are able to
> > With MSMQ, each message has a unique id, so, if my app restarts, it
> > can just peek tha last message it has been processsed and then
> > continue peeking the remaining messages.
> Publishers (app A) could add a unique ID to messages in a header when
> publishing which can be used in the same way.
> > I concurrent to the B app, on demand another B is comming to the
> > same queue, evealuating the same messages with our rules.
> It is possible for multiple consumers to read from the same queue. See
> tutorial 2:
> > The is probbaly more a CEP app with a fast temporary store [to avoid
> > databases]. This works exceptionally fast with MSMQ and I am abel to
> > read more then 15k messages/s.
> RabbitMQ is generally able to exceed that frequency, though it depends
> greatly on consumers keeping up, the messaging pattern and hardware
> being employed.
> For notes about performance see these blog posts:
> > A good note, hint or ref to a doc or something could really help me a
> > lot. I am using C#/mono.
> You may find this book of interest:
> RabbitMQ has ships with a mature C# client:
More information about the rabbitmq-discuss