1
我們有一個biztalk服務器2010標準版，用於將消息路由到十幾個合作伙伴。BizTalk消息狀態：排隊（等待處理）
對於少數合作伙伴，我們直接將傳入消息路由到合作伙伴，只包括一些地圖將消息轉換爲所需的格式。
對於其他合作伙伴，我們有一個合適的編排來將信息分批發送到一起，以減少我們必須發送的文件數量（尤其是通過FTP連接時）。這些編排從凌晨1點運行到晚上11點，每隔20分鐘或X消息發出批量文件。我們在凌晨收到大部分消息。
這在過去很好，但突然有些東西不像預期的那樣工作了。 當我們從凌晨1點開始收到消息時，我們可以看到這些批處理文件在凌晨2點左右發送給合作伙伴，然後突然停止工作。在重新啓動這些業務流程的主機實例之後，我們可以看到biztalk繼續發送批處理文件，但只有另外10分鐘左右，我們必須重新啓動實例。
我們看到我們有超過50k條消息的狀態爲「排隊（等待處理）」。經過幾次重新啓動並且沒有更多的排隊消息，一切都可以正常工作（但我們白天的流量較少）
行爲在部署後開始，但唯一的變化是在我們調用的程序集內其中一個管絃樂隊，但變化是非常小的（只是在條件變化）。
我檢查了應用程序日誌，但沒有提示任何限制，也沒有提到日誌中提到的任何錯誤。
你有什麼想法，我可以找到一些信息發生了什麼？
您的幫助是最感謝！
謝謝你和問候 邁克爾
- 2013年8月23日：
我剛安裝CU6我們驗收制度併發送5000條消息到BizTalk。 5業務流程（每方需要一個，我們給他們分批消息）開始，過了片刻我看到這些排隊的消息：
我有寫批處理消息的發送文件端口文件系統。它工作正常約4分鐘，編制一旦100個消息到達，就創建了一個文件。此後，它等了10分鐘超時並創建了一個文件，但較少的消息，即使認爲有
發送端口實例是否處於「隊列（等待處理）」狀態或協調實例？您是否以任何方式使用有序交付？你在使用動態端口嗎？ –
嗨，尼克，是的，我們使用有序交付，因爲我們使用順序車隊在一個編排中一起批量消息。編排實例處於狀態「正在運行」。我們使用直接端口綁定。消息本身處於「排隊」狀態，並等待編排來接收它們。 – MFox
Singleton Orchestration實例是否自行終止或者它只是永遠運行？ –