2

We are using WCF services hosted on IIS at middle tier and use a WPF client. We are seeing these errors in our production logs. From google i was pointed to a link here http://kennyw.com/indigo/150 that clearly says that this error is related to MaxConcurrentSessions.

The production log details below says that error happens when the WPF client is trying to open the WCF proxy connection using ICommunicationObject.Open() This error on our production system happens very frequently but i am unable to reproduce this error on my local setup. I tried to change the MaxConcurrentSessions to 1 and then opened 5 instances of the WPF application, on the WPF application the default dashboard has a timer running every 1 minute trying to get data, but still i am unable to reproduce this error.

My question is really when does this error happen, from the link above it says that this happens when the server is stressed out but in my test case above it should have been loaded. I also need to be able to reproduce this to even attempt to fix.

Any ideas if i am on the right path, is the MaxConcurrentSessions the right place to look at and how do i simulate this on local. Please help.

2/16/2012 4:10:40 PM:Information:Exception in the ServiceCall constructor:       System.ServiceModel.CommunicationException: 
  The socket connection was aborted. 
  This could be caused by an error processing your message or a receive timeout being   exceeded by the remote host, or an underlying network resource issue. 
  Local socket timeout was '00:00:59.9687730'. --->System.Net.Sockets.SocketException: 
An existing connection was forcibly closed by the remote host at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags) at System.ServiceModel.Channels.SocketConnection.ReadCore(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout, Boolean closing)
 --- End of inner exception stack trace ---
 Server stack trace: 
 at System.ServiceModel.Channels.SocketConnection.ReadCore(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout, Boolean closing)
 at System.ServiceModel.Channels.SocketConnection.Read(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout)
 at System.ServiceModel.Channels.DelegatingConnection.Read(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout)
 at System.ServiceModel.Channels.ConnectionUpgradeHelper.InitiateUpgrade       (StreamUpgradeInitiator upgradeInitiator, IConnection& connection, ClientFramingDecoder decoder, IDefaultCommunicationTimeouts defaultTimeouts, TimeoutHelper& timeoutHelper)
 at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.SendPreamble(IConnection connection, ArraySegment`1 preamble, TimeoutHelper& timeoutHelper)
 at  System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.DuplexConnectionPoolHelper.AcceptPooledConnection(IConnection connection, TimeoutHelper& timeoutHelper)
 at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)
 at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan timeout)
 at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
 at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
 at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
lloydom
  • 377
  • 2
  • 11

3 Answers3

2

There is a good chance the root cause of your problem is the improper disposable of the service proxy instances in your WPF app. Look at how the proxies are instantiated and disposed.

If your the code isn't following one of the patterns described in the answers to this SO question then you're not freeing up the TCP connections properly. This issue tends to popup most when using bindings that depend on TCP sessions.

Community
  • 1
  • 1
Sixto Saez
  • 12,610
  • 5
  • 43
  • 51
  • We are using the using block for each connection;overriden the Idispose to remove the object, which is a clean way to do it. --------------------------------public void TryCloseOrAbort(ICommunicationObject obj) { if (obj != null) { if (obj.State != CommunicationState.Faulted && obj.State != CommunicationState.Closed) {try { obj.Close(); } catch (CommunicationObjectFaultedException) { obj.Abort(); } catch (TimeoutException) { obj.Abort(); } catch (Exception){obj.Abort();throw;} }else obj.Abort();}} – lloydom Mar 21 '12 at 12:59
  • The only thing I see in that code that is a little strange is it can call Abort() on an obj instance that has obj.State == CommunicationState.Closed. Try checking the [ICommunicationObject documentation](http://msdn.microsoft.com/en-us/library/ms789041.aspx) to see if that may cause an issue in the disposal process. – Sixto Saez Mar 21 '12 at 13:29
  • thanks for your reply sixto, The link says that calling abort on communication state value of closed doesnt cause a problem "The Abort() method does nothing if the current state is Closed or if the object has been terminated before " , so it shouldnt cause this problem i am seeing. Hmmm do you think the error is only because of the using block? ---------------------------------------------------Using (var svc = new ServiceCall(endpointName)) { serviceCallType = svc.GetType(); // Invoke caller's implementation of the service call serviceCallBody(svc); } – lloydom Mar 22 '12 at 08:36
  • 1
    All the using statement does is wrap your code in `try { //your code } finally { //dispose of the instance created in the using line }`. If you're overriding Dispose(), it's just calling your dispose logic. The only way to verify that your code is properly disposing of the proxy instances is to analyze memory dumps of your application using [WinDbg](http://msdn.microsoft.com/en-us/windows/hardware/gg463009). Look at the garbage collection heaps for the specific .NET type of your proxy instances (the command is !dumpheap -type YourType) and see if they are in a gcroot chain. – Sixto Saez Mar 22 '12 at 12:42
0

Put this line in App.Config in Consumer side

<system.net>
   <defaultProxy useDefaultCredentials="true">
     <proxy usesystemdefault="True" bypassonlocal="True"/>
  </defaultProxy>
 </system.net>
Diego
  • 2,238
  • 4
  • 31
  • 68
0

There could be a couple causes for that error. MaxConcurrentSessions being one of them.

In your config file for both the server and the client be sure to increase the receiveTimeout and sendTimeout. You may be exceeding the time that is allowed by these parameters.

You need to make sure that both the server and the client have the same config values for these fields. If you only change one of them, the other could still timeout early.

Beyond that, the MS reference for their XML configs is below and may help you to find what is causing the issue.

http://msdn.microsoft.com/en-us/library/ms731354.aspx

Kevin Green
  • 1,137
  • 11
  • 21