Recently, I came across a scenario where client application was intermittently failing to connect to a WCF Service with ServiceTooBusyException. The binding had secure conversation enabled.
Of course, the very first plan we followed was to capture powerful WCF traces which were on the spot. We saw traces full with following warnings which confirmed that there’re too many pending security sessions being leaked.
What is Pending security session?
A Security sessions that is established with the server for which service has issued a session token but for which no application messages are sent. For example, client application creates the channel and calls open (channel.Open()). Open call will establish the secure session between client and service. Now, this secure session is added to pending secure session list until client application invokes a WCF operation on this channel.
By default, Pending security session limit is 128. As the pending security session limit was exceeded, WCF service didn’t accept new sessions and client application failed with ServiceTooBusy exception.
Next action for us was to find out why there’s no operation invoked by client and leaving security session as pending security session!
With extensive code review, we found that client application had code for some functionality as follows,
a) New client channel was created and open method was called i.e. Channel.Open().
b) However, the operation was executed if there’s certain conditions met
c) Then, channel.close was called to close the channel
If we look at above code, it looks pretty fine and shouldn’t cause Pending security session to leave open as channel was closed no matter if operation on channel was invoked or not. So, what’s causing so many Pending security sessions in our case?
Researching further, we found that there’s known bug with WCF which doesn’t remove security session from pending security session list if client just opens the channel and closes it. This bug is fixed in .Net Framework 4.5. Upgrading the servers to .Net framework 4.5 helped to resolve the issue.
However, unlike our scenario, it’s also possible to exceed pending security session limit if the service is loaded with burst load. In that case, it requires increasing default limit (128). To increase the default pending security session limit, it requires to convert the standard binding to custom binding and increase pending security session under localServiceSettings element,
<localServiceSettings maxPendingSessions="1024" />
Hope this helps to save someone's time.