Identify WCF clients that are not properly disposed
We have a WCF service hosted inside IIS. There are now many different client applications that call this service. WS-SecureConversion is used.
The service diagnostic log now displays warnings that security sessions are being interrupted. This is most likely due to clients not closing the session.
Additional information: The problem was with "pending" security sessions. These are sessions that have never been used, just opened. This is quite annoying as you can have up to 128 such sessions pending before your services start at 500.
This can be easily reproduced (see answer below). I was able to request 128 SessionInitiationMessageHandlers using WinDbg. Thus, it can be a good measure to identify this scenario.
However, it would be possible to define a way to identify these "bad" clients.
Regards, Alex
source to share
Since the client and server have nothing in common other than the messages going between them, you can hardly do this.
On the server side, you can watch some bits of information being sent from the client - check the property OperationContext.Current
in your service method - see the MSDN documentation on OperationContext for details of what exactly is provided.
Thus, you can register certain information to identify "abusive" customers.
Mark
source to share
Sweet ... the best way to kill a WCF service using a safe transform doesn't seem to matter.
ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };
var client = new MyClient();
client.ClientCredentials.UserName.UserName = "user";
client.ClientCredentials.UserName.Password = "password";
while(true)
{
Console.WriteLine("OPEN");
var c = client.ChannelFactory.CreateChannel();
((ICommunicationObject)c).Open();
// If I comment the following line, the service throws a
// "Too busy, too many pending sessions" 500.
var request = new MyRequest { };
c.Do(request);
// Of course I did *not* comment this line
((ICommunicationObject)c).Close();
}
In the meantime, this bug has been confirmed by MS, but still remains in .NET 4.x even though MS says otherwise:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=499859
source to share