Tuning JMS consumer speed (acknowledge)

[Jan Bares <ja...@wood.cz>]

Hi,

I noticed high consumer speedup (>10x) when I do not acknowledge individual messages but bunch of them at once. I use client acknowledge mode as in the case of failure to correctly process the message I may lose it. Seeing message more than once is not a (big) problem. Currently I consume with MessageListener.onMessage() but this doesn't allow me to acknowledge batch of messages - I do not know in advance when next message will come (if any) so the messages might be in acquired state for long time. With MessageConsumer.receive(timeout) I could read the messages and acknowledge batch of them and in the case of timeout, acknowledge them too. What are suggested values for timeout and batch size? Are there other options to check and tune? The broker is C++ 0.18.

Thank you, Jan



DISCLAIMER
________________________________
         WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
         Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
         This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Tuning JMS consumer speed (acknowledge)

[Robbie Gemmell <ro...@gmail.com>]

This is essentially the same as batched transactions, and this does usually
increase performance a fair amount (where you have enough messages of a
small enough size that performance isnt governed by available of messages
of network bandiwdth) because you performing fewer synchronous round trips
to the broker.

There is no particular recommended value to use for the timeout in this
situation, it is something you would choose based on evaluation of your
expected workloads and metrics you find most important. A very small
timeout could mean that little gaps in message availability mean you end up
performing more batches than you desire and limit overall performance
uplift. A large timeout could lead to a significant delay in acknowledging
the previously processed messages, though you could work around that by
having overall-time and number-of-messages bounds on when you
acknowledge/commit the batch. Its all essentially a balance that you need
to decide based on your use case.


On 9 April 2014 11:39, Jan Bares <ja...@wood.cz> wrote:

> Hi,
>
> I noticed high consumer speedup (>10x) when I do not acknowledge
> individual messages but bunch of them at once. I use client acknowledge
> mode as in the case of failure to correctly process the message I may lose
> it. Seeing message more than once is not a (big) problem. Currently I
> consume with MessageListener.onMessage() but this doesn't allow me to
> acknowledge batch of messages - I do not know in advance when next message
> will come (if any) so the messages might be in acquired state for long
> time. With MessageConsumer.receive(timeout) I could read the messages and
> acknowledge batch of them and in the case of timeout, acknowledge them too.
> What are suggested values for timeout and batch size? Are there other
> options to check and tune? The broker is C++ 0.18.
>
> Thank you, Jan
>
>
>
> DISCLAIMER
> ________________________________
>          WOOD & Company Financial Services, a.s. and its branches are
> authorized and regulated by the CNB as Home State regulator and in Poland
> by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State
> regulators. For further information about WOOD & Co., its investment
> services, financial instruments and associated risks, safeguard client
> assets (incl. compensation schemes) and contractual relationship please see
> our website at www.wood.com<http://www.wood.com/> under section Corporate
> Governance.
>          Unless otherwise stated, this transmission is neither an offer
> nor the solicitation of an offer to sell or purchase any investment. All
> estimates, opinions and other information contained herein are subject to
> change without notice and are provided in good faith but without legal
> responsibility or liability. Opinion may be personal to the author and may
> not reflect the opinions of WOOD & Co. Communications from sales persons,
> sales traders or traders should not be regarded as investment research and
> may contain opinions or trading ideas which are different from WOOD & Co.
> investment research opinions.
>          This e-mail and any attachments are confidential and may be
> privileged or otherwise protected from disclosure. If you are not a named
> addressee you must not use, disclose, distribute, copy, print or rely on
> this e-mail and any of its attachments. Please notify the sender that you
> have received this email by mistake by replying to the email, and then
> delete the email and any copies of it. Although WOOD & Co. routinely
> screens e-mails for viruses, addressees should scan this e-mail and any
> attachments for viruses. WOOD & Co. makes no representation or warranty as
> to the absence of viruses in this e-mail or any attachments. Please note
> that to ensure regulatory compliance and for the protection of our clients
> and business, we may monitor and read e-mails sent to and from our
> server(s).
> ________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>