Hi Sergey,
For Qpid to guarantee 'at-least-once' delivery on publish, you don't need to
use transactions.
Broker failures
-----------------
(1) In a stand-alone-broker you need to use persistence to ensure that
messages survive a broker crash.
(2) In a clustered broker you may be able to get away without using
persistence (*)
(*) Only the c++ broker supports clustering.
If you don't use persistence, then in the event of a total cluster
failure you will loose messages.
Therefore it depends on how much you can tolerate these occasional
failures.
Application/Client lib failures
---------------------------------
In the event of a failure in the application that sends the messages, you
may loose messages.
i.e if there are unacked messages in the client libs replay buffer, they
will be lost.
You could avoid that by using
For JMS client
-------------------
(1) Using synchronous publishing. Use
-Dsync_publish={persistent|transient|all}.
(2) Transaction - as Marnie pointed out.
Performance wise there isn't much of a difference between option 1 & 2 if
you use large batches (ex 1000 msg/batch) for transactions.
But ff you use small tx batches then there is an appreciable difference in
performance.
Therefore I recommend you use -Dsync_ack=persistent.
Also the application code is much simpler when writing non transactional
code.
For other clients
--------------------
If you can handle reliable replay at the application level then you could
just use asynchronous publishing without worrying about application failure.
Ex. If your application is retrieving orders from a queue and processing it
before sending a reply, then you could ack the order messsage after the
broker acks your reply message.
Hope this helps.
Rajith
On Wed, Mar 23, 2011 at 11:21 AM, Marnie McCormack <
[email protected]> wrote:
> Hi Sergey,
>
> To achieve guaranteed message delivery you need to be using transactions on
> *publish*. Qpid then guarantees 'at least once' delivery. You'd offset the
> reliable delivery cost against the cost or message loss during a failure
> from sending non-transacted messages. The use of transactions and
> persistence for reliable messaging adds cost in the shape of I/O.
>
> However, you could opt not to use transactions on consume since you cannot
> conceptually lose a message during consumption - if there's a failure and a
> message ack doesn't get back to the broker then you'll simply get the
> message back again on restart. This assumes that you listen/catch/handle
> errors and exception on consume such that you don't have application level
> side effects.
>
> Regards,
> Marnie
>
> On Tue, Mar 22, 2011 at 1:03 PM, <[email protected]> wrote:
>
> > Hi there
> >
> > I'm working with qpid 0.8 by means of JMS API and I'm using
> > CLIENT_ACKNOWLEDGE mode to get higher performance comparing to
> > transactinal processing.
> > As a rule performance is rather pure in both cases. In transactional mode
> > I can receive about 1.6K messages per second, in CLIENT_ACKNOWLEDGE mode
> > I'm able to receive about 3.6K messages per second and in
> AUTO_ACKNOWLEDGE
> > mode I'm able to receive about 70K messages per second.
> >
> > Are there any recommendations how to improve performance and get a
> > guaranted message delivery?
> >
> >
> > Best Regards,
> > Sergey
> > _______________________________________________________
> >
> > The information contained in this message may be privileged and conf
> > idential and protected from disclosure. If you are not the original
> intended
> > recipient, you are hereby notified that any review, retransmission,
> > dissemination, or other use of, or taking of any action in reliance upon,
> > this information is prohibited. If you have received this communication
> in
> > error, please notify the sender immediately by replying to this message
> and
> > delete it from your computer. Thank you for your cooperation. Troika
> Dialog,
> > Russia.
> > If you need assistance please contact our Contact Center (+7495) 258
> 0500
> > or go to www.troika.ru/eng/Contacts/system.wbp
> >
> >
>
