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.