none
.Net TCP reliable session heavy load service becomes unavailable after running a while RRS feed

  • Question

  • Hi,

    The below problem is my long time headache. So far I haven't got a correct solution. Any idea? Thanks advance.

    I have a .Net TCP reliable session heavy load service hosted by IIS 7 running on Windows 2008 R2 (net 4.5).

    It works perfect when the service started. But after a while, client will get exception, Open Connection Time out. The service is heavy load, 300 calls /sec. Per my observation,  The service after running a while, the calls is less and less until 0. At that time, client get Open connection time out. Looks like the service stopped. But I check I can see, the service and app pool are both "started" state, and I can see the process from task manager. But definitely CPU usage of this process is zero.

    I'm using Custom Binding on client and server side.

    Server Binding:

    <binding name="CustomSecureTcp" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:30:00">
        <binaryMessageEncoding>
           <readerQuotas maxDepth="32" maxStringContentLength="2147483646" maxArrayLength="2147483646" maxNameTableCharCount="2147483646" />
        <binaryMessageEncoding>
        <sslStreamSecurity requireClientCertificate="false" />
        <reliableSession enabled="true" ordered="true" maxPendingChannel=100 />
        <tcpTransport portSharingEnabled="true" listenBacklog="5000" >
           <connectionPoolSettings  groupName=”String” idleTimeout = "00:00:10" leaseTimeout="00:02:00" maxOutboundConnectionsPerEndpopint="500" />
         </tcpTransport>
      </binding>
     </customBinding>

    Client Binding

    <binding name="CustomSecureTcp" closeTimeout="00:01:00" openTimeout="00:01:00" sendTimeout="00:30:00">
        <binaryMessageEncoding>
           <readerQuotas maxDepth="32" maxStringContentLength="2147483646" maxArrayLength="2147483646" maxNameTableCharCount="2147483646" />
        <binaryMessageEncoding>
        <sslStreamSecurity requireClientCertificate="false" />
        <reliableSession enabled="true" ordered="true" maxPendingChannel=100 />
        <tcpTransport portSharingEnabled="true" listenBacklog="5000" >
           <connectionPoolSettings  groupName=”String” idleTimeout = "00:00:10" leaseTimeout="00:02:00" maxOutboundConnectionsPerEndpopint="0" />
         </tcpTransport>
      </binding>
     </customBinding>

    Friday, July 10, 2015 1:04 PM

Answers

  • hi Fred,
       According to this case, Timeouts are not directly related to throttling properties, but effect the way the service (or client) performance under load. Timeout properties can be perceived as an annoyance when sending larger messages or dealing with slow connections or services

    ReceiveTimeout (TimeSpan)  >> the interval of time that a connection can remain inactive, during which no application messages are received, before it is dropped. The default is 00:10:00.

    • This setting is only used on the server-side and has no effect on client-side
    • When using Reliable Sessions remember to set the InactivityTimeout property on the reliableSession element to the same value as the ReceiveTimeout property, as both inactivity timers has to be satisfied.

    you can try like below in server side binding :

    <binding name="CustomSecureTcp" closeTimeout="00:01:00" openTimeout="00:01:00" 
    receiveTimeout="00:10:00" sendTimeout="00:30:00"> <binaryMessageEncoding> <readerQuotas maxDepth="32" maxStringContentLength="2147483646" maxArrayLength="2147483646" maxNameTableCharCount="2147483646" /> <binaryMessageEncoding> <sslStreamSecurity requireClientCertificate="false" /> <reliableSession enabled="true" ordered="true"
    inactivityTimeout="00:10:00" /> <tcpTransport portSharingEnabled="true" listenBacklog="5000" > <connectionPoolSettings groupName=”String” idleTimeout = "00:00:10" leaseTimeout="00:02:00" maxOutboundConnectionsPerEndpopint="500" /> </tcpTransport> </binding> </customBinding>  
    Monday, July 13, 2015 7:50 AM

All replies

  • hi Fred,
       According to this case, Timeouts are not directly related to throttling properties, but effect the way the service (or client) performance under load. Timeout properties can be perceived as an annoyance when sending larger messages or dealing with slow connections or services

    ReceiveTimeout (TimeSpan)  >> the interval of time that a connection can remain inactive, during which no application messages are received, before it is dropped. The default is 00:10:00.

    • This setting is only used on the server-side and has no effect on client-side
    • When using Reliable Sessions remember to set the InactivityTimeout property on the reliableSession element to the same value as the ReceiveTimeout property, as both inactivity timers has to be satisfied.

    you can try like below in server side binding :

    <binding name="CustomSecureTcp" closeTimeout="00:01:00" openTimeout="00:01:00" 
    receiveTimeout="00:10:00" sendTimeout="00:30:00"> <binaryMessageEncoding> <readerQuotas maxDepth="32" maxStringContentLength="2147483646" maxArrayLength="2147483646" maxNameTableCharCount="2147483646" /> <binaryMessageEncoding> <sslStreamSecurity requireClientCertificate="false" /> <reliableSession enabled="true" ordered="true"
    inactivityTimeout="00:10:00" /> <tcpTransport portSharingEnabled="true" listenBacklog="5000" > <connectionPoolSettings groupName=”String” idleTimeout = "00:00:10" leaseTimeout="00:02:00" maxOutboundConnectionsPerEndpopint="500" /> </tcpTransport> </binding> </customBinding>  
    Monday, July 13, 2015 7:50 AM
  • Hi Edwin,

    First thanks for you reply.  I set inactivityTimeout already, for some reason, inactivityTimeout missed from the post.

    Anyway, I do think on service side, inactivityTimout should be less or the same as receiveTimeout. My original setting is "00:30:00". I changed to "00:10:00" as you suggested. No difference, the service is still not responding after a few hours. I suspect some limits has been hit. But not sure which it is. The service trace log didn't give me any clue.

    Thursday, August 6, 2015 11:47 PM