none
WCF not properly cleaning up pending secure conversations

    Question

  • Hi,

    I recently received an HTTP 500 saying "There are too many pending secure conversations on the server."

    A pending secure conversation should be one that has been established but not used by an operation call.

    However, even if a client closes its channel/client properly, the pending conversions is not cleaned up and the server goes down eventually.

    The following sample demonstrates this. It will crash a standard "Hello world!" service created by the Visual Studio template.
                while(true)
    {
    Console.WriteLine("OPEN");

    var client = new ServiceReference2.Service2Client();
    client.Open();
    // As soon as I call the DoWork operation here, the service stays healthy.
    client.Close();
    }
    Someone sharing the opniniion that this is a WCF f*** up? Or am I missing something?

    Thanks,
    Alex
    Alex
    • Edited by Alex80 Sunday, October 18, 2009 7:07 AM
    Saturday, October 17, 2009 3:52 PM

Answers

  • Microsoft confirmed this to be a known issue in .NET 3 framework.

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=499859&wa=wsignin1.0

    Alex
    • Marked as answer by Alex80 Sunday, June 06, 2010 4:50 PM
    Sunday, June 06, 2010 4:50 PM

All replies

  • Additional question:

    The default limit for those pending sessions is 128. Which is pretty low in my opinion.

    Imaging an intranet scenario and a new client component gets deployed. Certainly I would like to survive the event of a buggy client being shipped. I would tend to set this value to pretty high number and hope that the cleanup timeout catches up quickly enough. Let's say more like 65k. Memory consumption wouldn't be the problem.

    Is there a severe performance penalty in increasing this value? Or what are other reasons that this limit is so low?

    Cheers,
    Alex
    Alex
    Saturday, October 17, 2009 7:45 PM
  • Hi,

    I guess you need to up your maxPendingSessions. Are you using wsHttpBinding?
    Sunday, October 18, 2009 2:21 AM
  • Yes, I do. That's my second post about why this value is so low by default and what performance impact is has.

    However, as I am explicitly closing the client in my test code, the problem shouldn't occur at all.

    Alex
    • Marked as answer by Bin-ze Zhao Thursday, October 22, 2009 9:08 AM
    • Unmarked as answer by Alex80 Thursday, October 22, 2009 12:13 PM
    Sunday, October 18, 2009 7:04 AM
  • Hi,

    You probably need to create a custom bindings to increase the maxPendingSessions property value, see the discussion here:

    http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-web-services/5594/Too-many-pending-secure-conversations

    Thanks
    Binze
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, October 23, 2009 3:42 AM
  • Hi Binze,

    thanks for your reply!

    However, I don't agree with that article you reference. It says " The default number of secure connections allowed is 128 on a 2 minute timeout". Of course, a service does allow more then 128 secure connections/conversations per two minutes.

    It also doesn't answer the questions on the impact that a change on the maxPendingSessions setting has:

    >> Is there a severe performance penalty in increasing this value? Or what are other reasons that this limit is so low?

    Do you have further information more precise information on that?

    Thanks in advance,
    Alex

    Alex
    Friday, October 23, 2009 6:39 AM
  • Hi,

    The maxPendingSessions is a property of LocalServiceSecuritySettings of SymmetricSecurityBindingElement, you can change this value programmatically through :

                WSHttpBinding b = new WSHttpBinding();

                // Get the binding element collection.
                BindingElementCollection bec = b.CreateBindingElements();

                // Find the SymmetricSecurityBindingElement in the colllection.
                // Important: Cast to the SymmetricSecurityBindingElement when using the Find
                // method.
                SymmetricSecurityBindingElement sbe = (SymmetricSecurityBindingElement)bec.Find<SecurityBindingElement>();

                LocalServiceSecuritySettings lss = sbe.LocalServiceSettings;
                lss.MaxPendingSessions = 500;

    Then pass the binding to your service endpoint or the alternative way is create a custom binding with this SymmetricSecurityBindingElement and change the MaxPendingSessions value to appropriated number, then register this custom binding to your service endpoint.

    <customBinding>
            <binding name="cutom">
              <security>
                <localServiceSettings maxPendingSessions="500"/>
              </security>
            </binding>
          </customBinding>

    Thanks
    Binze


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    • Marked as answer by Alex80 Monday, October 26, 2009 10:41 AM
    • Unmarked as answer by Alex80 Sunday, June 06, 2010 4:48 PM
    Monday, October 26, 2009 3:45 AM
  • Thanks Binzen for the comprehesinve description regarding the workaround!

    Alex

    Alex
    Monday, October 26, 2009 10:42 AM
  • Microsoft confirmed this to be a known issue in .NET 3 framework.

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=499859&wa=wsignin1.0

    Alex
    • Marked as answer by Alex80 Sunday, June 06, 2010 4:50 PM
    Sunday, June 06, 2010 4:50 PM
  • This is NOT FIXED!!!!!!!

    I spent 4 days investigating this in .NET 4.0 to realise it is NOT fixed.

    Repro is easy:

    ChannelFactory<IFoo> foo = new ChannelFactory<IFoo>("binding");
    foo.Open();
    foo.Close();
    
    
    After 128 calls you get the error



    Ali Kheyrollahi

    • Proposed as answer by aliostad Tuesday, August 21, 2012 10:48 AM
    Tuesday, August 21, 2012 10:41 AM
  • Under .Net 4.5 the bug is fixed.

    However the client needs to be .Net 4.5 if only the Server is .Net 4.5 and the client is not the error still remains.

    Thursday, March 27, 2014 2:13 PM