Reliable messaging and Close sequence RRS feed

  • Question

  • We have a system where we have a WCF service (.Net 3.5). Client is not using WCF. We are using reliable messaging and it seems that there are protocol level issues. The service contains one-way messages and in each session only one message is sent (+protocol level messages).

    The problem we have is that  sessions are closed only after inactivity timeout. This means that, when there is a heavy load, we run out of the sessions. We are able to solve this by growing the number of maxConcurrentSessions and reducing the inactivity timeout, but it is still annoying.

    I looked this deeper and the reason for this is the following:

    Client ends the session with only TerminateSequence message. WCF understands this message correctly but it actually thinks that one message is missing and the situation is not clear. If I understand this ( correctly, then from WCF point of view the session should be ended with two messages: CloseSequence (which client does not send) and TerminateSequence. If the TerminateSequence message is sent without the preceding CloseSequence message, WCF terminates the sequence normally but releases the resources only after a timeout to give client a chance to receive the final acknowledgement.

    Ok, the questions I have are:

    1. Am I on the right track here, so it is really so that if client is sending only TerminateSequence, the the session is left open until inactivity timeout is reached?

    2. Is it possible to end the session (in service side) immediately after receiving the TerminateSequence message programmatically or by some configuration change?

    3. If the session count reaches maxConcurrentSession the sessions are stored to some pending session queue (size is maxPendingChannels). What happens if the count exceeds maxPendingChannels or inactivityTimeOut for those sessions? Is it possible that messages are silently dropped? The reason I'm asking this is that we had one test where client sent messages succesfully but they never reached our service. That was rather scrary because it seems to violate the whole idea of reliable messaging.


    Wednesday, June 19, 2013 11:03 AM

All replies

  • Any hints would be great.

    Monday, June 24, 2013 6:22 AM
  • Hi, InactivityTimeout indicates the idle timeout value that in the case of the client and the server side has been disconnected, during inactive periods, if the time is bigger than the set value, then trigger an event.

    I am not such clear understand you exactly issue here.

    Tuesday, June 25, 2013 6:32 AM
  • The issue (item 1&2) is that if client does not send CloseSequence then the sessions are closed only after a timeout. This means that we have open sessions that are actually closed in the client side but still pending in the service side.

    I dont know if this is a problem in principle, but we have have many issues because messages have been rejected alhough there was apparenly not much going on in the service side.

    Tuesday, June 25, 2013 8:22 AM
  • Hi,

    1. The WCF service (Reliable Messaging Destination) requires closeSequence before TerminateSequence for graceful way of closing out the sequence. If WCF receives TerminateSequence without closeSequence then the sequence will be terminated immediately by Reliable Messaging Destination (RMD) with a TerminateSequenceResponse message. I am not sure if the session left open until inactivity timeout is reached. As per my research, reliable session will not end based on inactive timeout.

    "If the sending application has no messages to send then the reliable session is normally not faulted because of inactivity; instead a keep-alive mechanism keeps the session active indefinitely. Note that the dispatcher could independently abort the reliable session if no application messages are sent or received. Thus, the inactivity timeout typically expires if network conditions are such that no messages of any sort are received or if there is a failure on the sender"

    Hence if the sequence is consistent, RMD waits and allows the application to receive final acknowledgement. If there is some inconsistent sequence and TerminateSequence received before closeSequence, the RDP raises a fault suspecting the fault in message delivery.

    2. You may be able to create a msgInspector to kill the session

    3. I am confused with this question. Once the session established, the message delivers as per the sequence. If the reliable session request count exceeds the maxPendingChannels then the new request itself will be denied and there is no message transmission.

    Please note that I have not tested these results on my machine. This needs more time to setup the environment. From a support perspective this is really beyond what we can do here in the forums. If you cannot determine your answer here or on your own, consider opening a support case with us.

    Visit this link to see the various support options that are available to better meet your needs:;en-us;offerprophone 


    Wednesday, June 26, 2013 8:42 PM