ActiveMQ的，如果客戶確認

終止前發生了什麼，我有一個持久的隊列，非事務處理，客戶承認，消費者閱讀jms.prefetchPolicy.queuePrefetch = 1 & wireFormat.maxInactivityDuration = 50000ActiveMQ的，如果客戶確認

和一次消費者處理消息，它確認消息。

如果消費者讀取消息，並且在發送確認之前，該過程突然終止，ActiveMq中會發生什麼？（這裏有什麼ActiveMq參數？）

與消費者需要10分鐘處理消息（因此消費者任務處於活動狀態並正在工作）不同，ActiveMq如何知道消息仍然是正在努力？（它是否監視TCP/IP連接，如果連接死亡，它假定該消息不會被確認？）

如何確定消息是否爲「毒丸」，即它使消費者崩潰？（如果消費者任務沒有死亡，則重新傳送計數似乎是有效的;消息中是否有內部計數器，表示「它已被讀取n次而未成功確認？」）

作爲實驗，我發送了6條消息，其中一條是「毒丸」（在消費者可以發送確認消息之前殺死消費者），同時有2個消費者正在運行（並且每當消費者死亡時自動重新啓動消費者以使計數達到2）。查看隊列（使用jconsole，使用broker.setUseJmx（true）啓用jmx），發送了4條消息，其中2條正在運行。爲什麼會有2個而不是隻有一個？

我一直在閱讀ActiveMq和JMS規範一段時間沒有明確答案，所以任何關於什麼參數發揮作用的見解，以及是否有任何已知的錯誤將非常有用。

來源

2012-06-28 Mary

這純粹是基於我的JMS的理解 - 可能不完全正確的：

如果消費者讀取消息，在此之前它可以發送一個ACK，過程突然終止，什麼ActiveMQ的發生

我的理解是，由於這發生在與JMS提供者的會話上下文中，因此JMS提供者知道該會話是否不再活動或失敗，並且任何未被確認爲會話一部分的消息將被重新發送會議重新建立。

如何確定消息是否爲「毒丸」，即它會使消費者崩潰？

就像你剛纔提到，JMS提供者跟蹤倍＃的消息是在消息的標題可能交還的

4條消息被交付，2個在飛行

不知道這一點

來源

2012-06-29 01:40:37

這有幫助，謝謝。我認爲ActiveMq意識到TCP/IP連接是否被破壞（甚至可能在用戶端有一個退出鉤子來更快地完成）。那些消息（其消費者突然退出）實際上正在重新發布。 – Mary

毒丸：我驗證了當我的消費者崩潰時，JMS確實保留了消息被重新傳遞的次數，所以我可以用它來確定它是否是「毒丸」消息（如果＃重試次數超過x，我將其記錄下來， ack）。代碼：org.apache.activemq.command.ActiveMQMessage amqMessage =（org.apache.activemq。command.ActiveMQMessage）jmsMessage; int redeliveryCounter = amqMessage.getRedeliveryCounter（）; – Mary

不錯，謝謝你的信息。 –

ActiveMQ的，如果客戶確認

回答

相關問題