Re: sync vs async sends (was Re: AMQ4.0-M2: Explanation for observed low

["massive.boisson" <ma...@gmail.com>]

As usual thanks for reply,

"Yes. In a transaction all operations are async - apart from the final
commit/rollback.

This is why for multiple-operations (like consuming a message and
sending multiple messages on) you should always use a JMS transaction
as its faster. "

So... I am sending 3 messages to persistent queue with jms.useAsyncSend=true
within a transaction and then commiting. Each send opens a new thread.
Commit blocks. The broker still waits for all 3 sends to be completed (and
persisted) before it returns from the commit, right? 

"Yes - the ExceptionListener should hear any exceptions.

I wonder if we could add a neater non-JMS extension to ActiveMQ to
make it easier to be notified asynchonously of which Message objects
could not be sent? I guess we could just use the ExceptionListener and
use a custom type of Exception which contained the Message object?"

Right, so I'd know something is wrong by listening to the ExceptionListener,
but I'd have no way of knowing which message didn't work correctly. 
And thus it would be great to have more detalis within
ActiveMqCustomException which would at least point to the problematic
message. 

--
View this message in context: http://www.nabble.com/AMQ4.0-M2%3A-Explanation-for-observed-low-throughput-...-t983076.html#a4833264
Sent from the ActiveMQ - User forum at Nabble.com.

Re: sync vs async sends (was Re: AMQ4.0-M2: Explanation for observed low

["massive.boisson" <ma...@gmail.com>]

The jira is http://issues.apache.org/activemq/browse/AMQ-751.

I put its priority as major, just because I don't know of easy work arround,
but that is obvioulsy debatable.

--
View this message in context: http://www.nabble.com/AMQ4.0-M2%3A-Explanation-for-observed-low-throughput-...-t983076.html#a4834964
Sent from the ActiveMQ - User forum at Nabble.com.

Re: sync vs async sends (was Re: AMQ4.0-M2: Explanation for observed low

[James Strachan <ja...@gmail.com>]

On 6/12/06, massive.boisson <ma...@gmail.com> wrote:
>
> As usual thanks for reply,
>
> "Yes. In a transaction all operations are async - apart from the final
> commit/rollback.
>
> This is why for multiple-operations (like consuming a message and
> sending multiple messages on) you should always use a JMS transaction
> as its faster. "
>
> So... I am sending 3 messages to persistent queue with jms.useAsyncSend=true
> within a transaction and then commiting. Each send opens a new thread.
> Commit blocks. The broker still waits for all 3 sends to be completed (and
> persisted) before it returns from the commit, right?

If you are sending using the same session and you are using async
sends or are inside a transaction then there's no need to create new
threads; just send each message, one after the other and the send()
method returns nearly immediately since its just putting the message
on an in memory buffer and ActiveMQ has a background thread doing the
send for you.

The only method that could take some time is the commit() (which waits
for everthing to be on disk before returning - unless you enable async
sends)


> "Yes - the ExceptionListener should hear any exceptions.
>
> I wonder if we could add a neater non-JMS extension to ActiveMQ to
> make it easier to be notified asynchonously of which Message objects
> could not be sent? I guess we could just use the ExceptionListener and
> use a custom type of Exception which contained the Message object?"
>
> Right, so I'd know something is wrong by listening to the ExceptionListener,
> but I'd have no way of knowing which message didn't work correctly.
> And thus it would be great to have more detalis within
> ActiveMqCustomException which would at least point to the problematic
> message.

Agreed - could you raise a new JIRA for this new feature request so we
don't forget it please?

-- 

James
-------
http://radio.weblogs.com/0112098/