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 <matth...@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.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 >> >> > > -- > 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
