On 1 Jan 2007, at 14:23, Sagi Mann wrote:
pls clarify: when async dispatch is enabled, each onMessage event
is handled
by a different thread which is created by the session. Correct?
Not necessarily - there will generally be only 1 thread of control
for the session. ActiveMQ can use more than 1 thread fro message
delivery to a session, as the threads can be gained from a pool, but
only one thread will be active at one time to ensure order of delivery.
but what
happens if those messages are further passed on to some app thread
(the
original threads are long dead)? Can the app thread still call
msg.ack()?
ActiveMQ can certainly handle this case, but the spec implies that a
JMS provider shouldn't be expected to. The minimum for JMS compliance
is that there should be only one thread of control (in this case the
thread calling the message listener) - so the message.acknowledge()
should be called from within the listener - not by another
application thread. A separate thread can be used to call stop/start
on a session but that its it.
cheers,
Rob
Thanks.
rajdavies wrote:
That applies to the application thread only - it's valid to call
message.acknowlede() from a message listener (for a session using
client based acknowledgement)
cheers,
Rob
On 1 Jan 2007, at 11:39, Sagi Mann wrote:
Hi all,
The JMS specs say that a session can only be used inside a single
thread. If
I handle consumed messages asynchronously, and call
message.acknowledge(),
doesn't this violate the single-thread specification?
Thanks,
--
View this message in context: http://www.nabble.com/Asynchronous-
dispatch-question-tf2903928.html#a8113066
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
--
View this message in context: http://www.nabble.com/Asynchronous-
dispatch-question-tf2903928.html#a8113836
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
