MaxSessionsPerAddress issue when using WCF PollingDuplex and Silverlight client

Question

WCF Trace logs shows many "The server has hit a PollingDuplex throttle, MaxSessionsPerAddress, and cannot accept another session from this client. An http error was returned" errors.

Can't find enough details about MaxSessionsPerAddress settings, just found this post which saying that MaxSessionsPerAddress always is 10 and cannot be changed.

Just thinking may be this issue related to a fault tolerance logic I've implemented for client proxy which together with some timeout results in such issue: In case of a channel failure WCF client proxy closes a channel (Close() then Aboort() in try/catch) and then tries to reconnect each 5 seconds, N retries. Perhaps a client was not able connect even after 10 retries what created 10 sessions on a service so all next retries were refused?

General information:

• PollingDuplex connection
• Cannot reproduce this issue since it was observed once in a live environment and then switched off to do not impact users
• IIS HTTPERR log has multiple Connection_Abandoned, Connection_Dropped entries for a failed service

WCF Client:

• Silverlight4
• ClientPollTimeout=5min
• InactivityTimeout=24h, SendTimeout=30min, CloseTimeout=3min
• ReceiveTimeout=24h, OpenTimeout=3min

WCF Server:

• IIS Hosted
• InstanceContextMode = PerSession
• ConcurrencyMode = Multiple
• maxConcurrentCalls, maxConcurrentSessions, maxConcurrentInstances are set to 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"
• maxReceivedMessageSize="1073741824", maxBufferSize="1073741824", MaxBufferPoolSize="2147483647"

Any help greatly appreciated!

Mascle

It may be that the service is running so slow it's failing to respond to the client request in a timely manner. You have three settings that likely consume way too much memory for your service. Do you really want to the service to process request message that can be up to 1 GB in size? Also, the MaxBufferPoolSize is set to an unrealistic size, 2 GB. Try deleting setting the maxBufferSize and maxBufferPoolSize attributes from the config file (or in code) and set maxReceivedMessageSize to a viable size for your application (likely below 2 - 3 MB) for both client & service. – Morass

Do you think these values somehow affects service behaviour or resources allocated before startup? Really I need few KBs but maximized those values to eliminate possible issues related to a message buffer size since now I do not know what to do with such errors – Mascle

I've seen performance issues caused by trying to max out these settings. The WCF defaults for these as are a good start. For example, maxBufferSize will automatically be set to equal maxReceivedMessageSize by WCF unless you override it by giving it set value. If are regularly passing very large (> 3 MB) requests to the service then you would want to set the maxBufferPoolSize value to match the maxReceivedMessageSize value. This MSDN Forum post has a good explanation of these settings. – Morass

@SixtoSaez : thansk for the link, seems a detailed description there.. reading now – Mascle

I was just reviewing the question again and noticed that you have InstanceContextMode set to PerSession and ConcurrencyMode set Multiple. Is there are reason you're not using the default values for these two settings, particularly the ConcurrencyMode = Multiple setting? – Morass

In each service instance (session) there are few threads created myself (TPL Task, 2 timer threads) which are responsible for different things, I was thinking this is why I need Multiple, perhaps I understand this mode not in a right way? – Mascle

The ConcurrencyMode is there to control how many request messages a single service instance will process and respond to. This MSDN article has a very good explanation of the behavior of the ConcurrencyMode setting with sample code which you should review to see if the Multiple setting makes sense for your application. – Morass

My service only pushes notification/updates back to the clients and since it is perSession - one request epr a client will be served, so not too much requests really but everything is done is thread safe – Mascle

Answer 1

Main reason was that a client eventually has been failed which forces a client to reconnect too often (each 5 seconds), after reconnect a server/service receives a client's request but client again has been fauiled, each reconnect created a new WCF service session which will terminate only in 2 minutes of client polling absence, so in 2 minutes one client created too many sessions on service side.

Why a silverlight client eventually has been faulted and disconnecting? See following post which describes an actual issue and a solution: WCF Silverlight client getting 404 not found response for poll message

Other issues and solution, which were applied, perhaps anybody found helpful:

Client:

Issue: Due to different reasons channel close operation can stuck for CloseTimeout="00:03:00" minutes what is too long

Solution:

• Set closeTimeout to 10 seconds so in case of any issue close operation will be forced in 10 seconds so client do cleanup quickly
• Increased reconnect timeout from 5 seconds to 30 seconds to let everything releated to old channel connection to be released/cleaned up

Service:

Issue: Sometimes I saw that service is stuck while a client callback invocation (CallbackContract) for sendTimeout=30minutes because cannot complete operation due to disconnected/faulted client so service cleanup delayed for 30 minutes but should be as fast as possible released/cleaned up and disposed in case of faulted/disconnected client

Solution:

• Set sendTimeout to 30 seconds, this is more than enough for sending few kilobytes message over the network

Mascle