activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <gary.tu...@gmail.com>
Subject Re: Slow producing of messages, expected behaviour?
Date Thu, 08 Jul 2010 14:45:48 GMT
It depends a little on the type of failure, a connection failure will
be propagated up the the send thread, but if the send fails in the
broker because of a configured memory limit (for example with
sendFailIfNoSpace=true), the connection will remain and the exception
will just be logged unless you have a listener registered, so you
won't know about this type of failure with an useAsyncSend.

On 8 July 2010 13:16, matthiask <matthias@yacc.se> wrote:
>
> useAsyncSend gave a tremendous speedup and I will try to work from here. I
> need to reasonably guarantee delivery though of messages, and currently
> everything is wrapped in a resender, meaning if JmsTemplate throws an
> Exception, the message and all subsequent are put into a memory queue and
> resending is automatically done until it succeeds. Pretty low-tech, but
> works great for when/if ActiveMQ is down for short periods of time.
>
> By just performing a simple test, this mechanism still worked when using
> async sends (shutting down ActiveMQ during sending) so I'm wondering if I
> have any additional need of the exception listener, if the exception is
> still (as it looks like) thrown.
>
> // Matthias
>
>
> Gary Tully wrote:
>>
>> 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.obrien@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
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Slow-producing-of-messages%2C-expected-behaviour--tp29044897p29106386.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>



-- 
http://blog.garytully.com

Open Source Integration
http://fusesource.com

Mime
View raw message