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 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