Hi Marco,

i replied to your email, didn't you get it?


Marco Buss wrote:
> 
> I think ActiveMQ shows the right behavior. The broker needs an ack for the
> receving of the message. The ack is not send to the server and so he sends
> the message twice because he thinks the message is not processed. The
> Broker dont`t know that the message is processed but the thread is closed
> before the ack is send. The right way for this would be to ensure the
> thread is closed after the ack is send.
> 
> [..]
> 
> Ok, that's ok. But it is not clear why you must use transactions. Please
> describe it a little bit. Sometime the transaction is not realy needed.
> 
Ok, why do we use transactions? We want to have the option to rollback - to
send the recieved message back to the broker and any other changes we made
(maybe we send messages to other queues, because we recieved a specific
messages...) should be removed. So with non-transacted session this isn't
possible, is it?

Please take a look at a 
http://www.nabble.com/file/p17729240/MyMessageConsumer.java new Consumer ;
it implements the MessageListener. In its onMessage()-method the session is
commited. When a call comes in to cancel the consumer, the MessageListener
of the consumer is set to null (so the onMessage-method will not be called
again) and thread is notified to close the consumer and the session. Closing
the consumer blocks until the onMessage()-method is left (due to the
specification). 

I don't see, where to change what to solve this problem.

I appreciate your interest and your effort!

Cheers,
 Kevin
-- 
View this message in context: 
http://www.nabble.com/Closing-a-consumer-create-more-messages-than-sent-tp17602690p17729240.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Reply via email to