In the async case, you can set an exception listener to get a calback in the event of an async failure.
On 1 July 2010 17:11, cobrien <clark.obr...@ttmsolutions.com> wrote: > > Matthias, > If do not require guaranteed delivery to the broker you can set > jms.useAsyncSend=true so the producer > does not wait for an acknowledgement from the broker before sending the > next > message. > > The caveat here is that if message is lost between the producer and broker > you will not be notified. > > Clark > > www.ttmsolutions.com > ActiveMQ reference guide at > http://bit.ly/AMQRefGuide > > > > > matthiask wrote: > > > > I'm trying to improve the performance of our backend and is currently as > > benchmark using a use case that takes about ~800 ms to execute and > > produces 40 JMS messages that are put on a queue (BytesMessage). Each > > message is a few kb. > > > > If I dummy out the JMS delivery, the same use case takes about 40 ms to > > finish, meaning that it spends most of it time waiting for messages to > get > > accepted by ActiveMQ. I have also verified this by profiling. > > > > The delivery is performed using a JmsTemplate, configured with a pooled > > connection factory. > > > > Without going into more detail, is this expected behavior, around 20 ms > or > > so for a message to get delivered, or am I missing something obvious that > > could speed this up. > > > > I'm currently looking at making architectural changes that would mean > that > > the actual sending of the messages don't need to be synchronized with the > > use case, but it would require some redesigning and I would rather see > > that I would be able to use the current "simple" approach with messages > > being sent as they are produced by the application. > > > > Any input or help would be greatly appreciated. Any more info I can > > provide? > > > > Matthias > > > > -- > View this message in context: > http://old.nabble.com/Slow-producing-of-messages%2C-expected-behaviour--tp29044897p29047632.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > > -- http://blog.garytully.com Open Source Integration http://fusesource.com
