WCF/MSMQ「接收時間已經過去」死信隊列問題

我正在測試我寫的一些軟件。測試通過WCF將消息排入MSMQ的速度快於我的軟件可以出隊和處理它們的速度。這應該不是問題，因爲這是MSMQ的預期目的，但如果我將足夠的消息排入其處理軟件超過24小時的時間，那麼這些消息將移至「事務性死信消息」隊列並且其類設置爲「接收時間已過去」「。WCF/MSMQ「接收時間已經過去」死信隊列問題

唯一的配置，我能找到的是在綁定本身：

<bindings> 
    <netMsmqBinding> 
    <binding timeToLive="7.00:00:00" /> <!-- 7 days --> 
...

我用這個既結合排隊和出隊的時候，它似乎並沒有這樣的伎倆。設置值2秒確實有效，但將其設置爲超過1天，包括其最大值（24天）不會。

是否有另一種方法來延長這個接收時間的窗口？我找不到任何其他配置（發送消息或創建隊列時）。

來源

2009-11-18 Langdon

我可以問你正在運行什麼操作系統？與您的問題無關，僅與MSMQ + WCF有關。我有一百萬令人頭疼的事情讓WAS工作。 – 2009-11-23 13:01:39

此刻Windows 2003。不幸的是，對於本地測試，一個盒子正在處理數據庫，WCF服務和MSMQ。現在我已經解決了TTL問題，現在我們將測試轉移到Amazon EC2上的多個框（仍然使用Windows 2003）。 – Langdon 2009-11-23 13:27:22

timeToLive屬性上的綁定本身，實際上是唯一可配置的必要條件。我回去了所有的配置，顯然錯過了一個位置。從「規劃WCF服務」：

的傳輸TimeToLive屬性僅到發佈客戶端相關的，已經在服務端沒有任何影響，也不可以在服務改變它。 TimeToLive 默認爲一天。

我已經完成了整個週末的測試，正在進行1,000,000條消息。沒有任何事情在死信隊列中結束。

來源

2009-11-23 12:50:51 Langdon

我不是100％確定，但我相信TimeToLive屬性只設置Time-To-Reach-Queue msmq屬性，但我不知道現在設置時間的內置方式要收到的財產...

來源

2009-11-18 20:11:32 tomasr

感謝您的輸入。這是一個令人討厭的問題。我見過一些建議，建議我創建一個自定義的死信隊列，監控它，並自動重試出現在其中的消息，但這看起來像是一個很大的問題來解決這樣一個簡單的問題。我的代碼很慢，只需要更多的時間！ :) – Langdon 2009-11-18 22:09:35

哦，我同意，它的煩人，沒有論據:)出於好奇，是你的服務器CPU綁定或IO綁定？ – tomasr 2009-11-18 23:34:32

目前CPU綁定（我們正在進行負載測試和基準測試以嘗試和改進事物）。我能夠比使用wsHttp更快地將消息發送到託管在IIS上的異步端點，比我能夠將它們轉發到MSMQ WCF終端上更加快速，在那裏處理它們並將它們發回給訂閱者......它是一個WS-Notification的實現。我已經提出了一些想法 - 我們沒有進行任何頻道緩存，而且我認爲每次創建新頻道時花費1/10秒。 – Langdon 2009-11-19 04:21:24

WCF/MSMQ「接收時間已經過去」死信隊列問題

回答

相關問題