8

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!

sll
  • 56,967
  • 21
  • 100
  • 149
  • 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. – Sixto Saez Dec 03 '12 at 14:22
  • 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 – sll Dec 03 '12 at 15:53
  • 1
    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](http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/d6e234d3-942f-4e9d-8470-32618d3f3212) has a good explanation of these settings. – Sixto Saez Dec 03 '12 at 16:32
  • @SixtoSaez : thansk for the link, seems a detailed description there.. reading now – sll Dec 03 '12 at 16:54
  • 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? – Sixto Saez Dec 05 '12 at 16:32
  • 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? – sll Dec 06 '12 at 09:10
  • The `ConcurrencyMode` is there to control how many request messages a *single* service instance will process and respond to. This [MSDN article](http://msdn.microsoft.com/en-us/library/ms752260.aspx) 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. – Sixto Saez Dec 06 '12 at 13:25
  • 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 – sll Dec 07 '12 at 10:59

1 Answers1

0

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
Community
  • 1
  • 1
sll
  • 56,967
  • 21
  • 100
  • 149