Session Lifetime on the Server



Why doesn't increasing the InactivityTimeout of a reliable session keep client connections alive for longer?

When using a reliable session, there are two different inactivity timers that must be satisfied to keep the connection alive. If either inactivity timer goes off, then the connection is killed.

The first inactivity timer is on the reliable session and is called InactivityTimeout. This inactivity timer fires if no messages, either application or infrastructure, are received within the timeout period. An infrastructure message is a message that is generated for the purpose of one of the protocols in the channel stack, such as a keep alive or an acknowledgment, rather than containing application data.

The second inactivity timer is on the service and uses the ReceiveTimeout setting of the binding. This inactivity timer fires if no application messages are received within the timeout period.

Since the connection is killed if either inactivity timer fires, increasing InactivityTimeout once it is greater than ReceiveTimeout has no effect. The default for both of these timeouts is 10 minutes, so you always have to increase ReceiveTimeout first to make a difference.

Next time: Glossary Updates

Comments (4)

  1. A ChannelFactory is a local client endpoint that can stamp out proxy instances for a remote service endpoint.

  2. Sam Gentile says:

    Temps near 100 F and 100% humidity make for some pretty uncomfortable days Windows Workflow Sometimes

  3. Sam Gentile says:

    Temps near 100 F and 100% humidity make for some pretty uncomfortable days Windows Workflow Sometimes

  4. Temps near 100 F and 100% humidity make for some pretty uncomfortable days Windows Workflow Sometimes you have to go beyond the two root models of WF which are Sequential and State. We needed to and ended up using a hybrid of rules driven and state. Matt

Skip to main content