WCF跟蹤日誌顯示許多"The server has hit a PollingDuplex throttle, MaxSessionsPerAddress, and cannot accept another session from this client. An http error was returned"錯誤。使用WCF PollingDuplex和Silverlight客戶端時MaxSessionsPerAddress問題

找不到有關MaxSessionsPerAddress設置的足夠的詳細信息，找到this post這就是MaxSessionsPerAddress始終爲10，無法更改。

只是想着可能是這個問題與我已經實現的客戶端代理的一個容錯邏輯，以及一些超時導致這樣的問題：在通道故障的情況下WCF客戶端代理關閉一個通道（關閉（）然後Aboort（）在try/catch中），然後嘗試重新連接每5秒，N次重試。即使在10次重試之後，客戶端可能無法連接在服務上創建了10個會話，因此所有下一次重試都被拒絕了？

一般資料：

PollingDuplex連接
不能重現這個問題，因爲它是在實際環境中觀察到一次，然後關閉，以不影響用戶
IIS HTTPERR日誌有多個Connection_Abandoned，對於失敗的服務

WCF客戶Connection_Dropped條目：

Silverlight4
ClientPollTimeout = 5分鐘
InactivityTimeout = 24H，的SendTimeout = 30分鐘，CloseTimeout = 3分鐘
ReceiveTimeout = 24H，OpenTimeout = 3分鐘

WCF服務器：

IIS Hos泰德
InstanceContextMode = PerSession
ConcurrencyMode =多
maxConcurrentCalls，maxConcurrentSessions，maxConcurrentInstances被設定爲500
HttpBinding，httpTransport，PollingDuplexBindingElement，DuplexChannelFactory
的SendTimeout = 「00:30:00」，receiveTimeout = 「24:00:00」，openTimeout =「00:10:00」，closeTimeout =「00:10:00」
maxOutputDelay =「00:00:01」，inactivityTimeout =「24:00:00」， serverPollTimeout =「00:02:00」
maxR eceivedMessageSize =「1073741824」，maxBufferSize =「1073741824」，MaxBufferPoolSize =「2147483647」

任何幫助非常感謝！

來源

2012-11-30 sll

可能是服務運行速度太慢，無法及時響應客戶端請求。您有三種設置可能爲您的服務消耗太多內存。你真的想要服務來處理請求消息，最大可以達到* 1 GB *的大小？此外，** MaxBufferPoolSize **被設置爲不現實的大小，* 2 GB *。嘗試從配置文件（或代碼中）中刪除設置** maxBufferSize **和** maxBufferPoolSize **屬性，並將** maxReceivedMessageSize **設置爲您的應用程序的可行大小（可能低於2 - 3 * MB *）客戶和服務。 –

您認爲這些值在某種程度上會影響啓動之前分配的服務行爲或資源嗎？真的，我需要幾個KB，但最大化這些值以消除與消息緩衝區大小有關的可能問題，因爲現在我不知道如何處理此類錯誤 – sll

我看到了嘗試最大化這些設置所導致的性能問題。 WCF默認爲這是一個好的開始。例如，* maxBufferSize *將自動設置爲等於* maxReceivedMessageSize * WCF，除非您通過給它設置值來覆蓋它。如果定期向服務傳遞非常大（> 3 MB）的請求，那麼您需要設置* maxBufferPoolSize *值以匹配* maxReceivedMessageSize *值。此[MSDN論壇帖子]（http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/d6e234d3-942f-4e9d-8470-32618d3f3212）對這些設置有很好的解釋。 –

主要原因是客戶端最終失敗，這迫使客戶端重新連接太頻繁（每5秒），重新連接服務器/服務後收到客戶端的請求，但客戶端再次被欺騙，每個重新連接創建一個新的WCF服務會話將僅在客戶端輪詢不在2分鐘內終止，因此在2分鐘內，一個客戶端在服務端創建了太多會話。

爲什麼Silverlight客戶端最終出現故障並斷開連接？請參見下面的帖子描述的實際問題和解決辦法：WCF Silverlight client getting 404 not found response for poll message

其他問題和解決方案，這些政策的應用，也許任何人發現的有用：

客戶：

問題：由於不同的原因渠道可以固定在接近操作CloseTimeout="00:03:00"分鐘什麼過長

解決方案：

設置closeTimeout至10秒，以便在任何問題關閉操作將被迫在10秒的情況下，這樣的客戶做清理工作迅速
增加重新連接超時從5秒到30秒，讓一切相關型號老通道連接是發佈/清理

服務：

問題：有時候我看到服務被套牢，而客戶端回調調用（CallbackContract）爲sendTimeout=30minutes因爲canno噸完整操作由於斷開/故障客戶端，以便服務清理延遲30分鐘但應該是儘可能快地釋放/清理和佈置在故障/斷開客戶端的情況下

解決方案：

將sendTimeout設置爲30秒，這對於通過網絡發送幾千字節的消息來說是綽綽有餘的

來源

2012-12-25 19:58:11 sll

使用WCF PollingDuplex和Silverlight客戶端時MaxSessionsPerAddress問題

回答

客戶：

服務：

相關問題