消费者在本地缓存消息并将其重新传递给客户端,直到满足重新传递计数为止,然后自动将消息认为是坏消息(posin ack)。消费者可以根据确认模式控制是否将其标记为重新发送。如果无论出于何种原因,消费者不能或不想处理消息,则它也可以将其踢回,并且如果它关闭会话,它将再次可用于消费。
经纪人将持有该消息,直到它从消费者得到一个确认。如果您的消费者设置为AUTO_ACKNOWLEDGE,那么如果发生未处理的异常或消费者意外终止,则可能会丢失消息。否则,如果您的消费者正在使用事务或CLIENT_ACKNOWLEDGE,它会给你对何时发生的控制。
对于事务,如果消费者在提交之前下降,它将可用于下一个消费者或消费者重新连接时。
我一直使用CLIENT_ACKNOWLEDGE事务,所以我不想肯定地说,如果Session.recover()在消费者关闭之前没有被调用,消息将会丢失。
从消费者的角度来看,这也被称为重试逻辑。
关于经纪人与消费者的重新交付:默认情况下,经纪人只是一直给消费者提供相同的消息,直到满足重新交付计数。如果您告诉经纪人在给定的时间后不要重新发送,那么您的消费者可以使用其他可能被处理的消息。
什么时候这样做是真的取决于你的应用程序正在发生什么。也许一个特定的消息需要被放到一个数据库中,并且该数据库目前不可用,并且您想要转移到其他地方的消息/有另一个目的?
这不完全正确。 ActiveMQ MessageConsumer确实拥有已在交易中交付的消息缓存,并将在发送回滚时将其本地重新发送至设置的重新传递限制。 – 2014-08-29 21:30:34
@TimBish感谢您的标注。我以为已经编辑过这个。我开始思考其他事情的回应。 – 2014-08-30 02:45:26
这是否意味着如果我们选择经纪人重新交付,那么消息将不会缓存在消费者身上,并且每次都来自代理(从而增加网络使用)?另一个问题是:是否有类似确认超时的情况,以便经纪人或消费者在一段时间后不重新发送消息而没有ACK? – Janek 2014-08-31 17:03:51