[rabbitmq-discuss] Migrating from MSMQ:Identifying queue features

[mabra at manfbraun.de]

Hello !

Thank you very much; I'll try to go in now.

Bye,

++mabra


> -----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
> features
> 
> 
> 
> Hi,
> 
> 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:
> http://www.rabbitmq.com/ttl.html
> 
> > 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
> http://www.rabbitmq.com/releases/rabbitmq-dotnet-client/v3.0.1/rabbitmq-
> dotnet-client-3.0.1-client-htmldoc/html/type-
> RabbitMQ.Client.IModel.html#method-
> M:RabbitMQ.Client.IModel.BasicReject%28System.UInt64,System.Boolean%29
> 
> 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
process.
> 
> > 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:
> http://www.rabbitmq.com/tutorials/tutorial-two-java.html
> 
> > 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:
> http://www.rabbitmq.com/blog/2012/04/17/rabbitmq-performance-
> measurements-part-1/
> http://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-
> measurements-part-2/
> 
> > 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:
> http://manning.com/videla/
> 
> RabbitMQ has ships with a mature C# client:
> http://www.rabbitmq.com/releases/rabbitmq-dotnet-client/v3.0.1/rabbitmq-
> dotnet-client-3.0.1-user-guide.pdf
> 
> 
> 
> -Emile
> 
> 
>