Fore some time ago I have a problem with objects that was using events and the original object (discoveryClient) cant be released and disposed. The problem this time was that the object was only referenced by event-handler and because of that you have a reference to the object and the GC was not able to discard the object. After remove the event-handler after the object was used fixed my memory-leak problem.

As an MS intern, I have an MS Q&A tech support card. Tell me if you need one :)

Funny enough I was looking at this problem last week about wcf service holding onto large amounts of memory it turned out to be a simple configuration change to the setting maxBufferPoolSize. When you look at a lot of examples about sending large files etc through wcf services everyone blindly sets all the settings (maxBufferSize, maxReceivedMessageSize etc) to huge values and ussually the maxBufferPoolSize get set to the same huge value. However, this value indicates the pool size not a buffer size. so you want to limit your buffer pool to a number of cached buffers and not let it run wild. Set the maxBufferPoolSize to 1 just to test this theory and your memory usage should drop dramtically (if it is this!).

I posted something on stackoverflow about this http://stackoverflow.com/questions/6713180/addressalreadyinuseexception-when-using-custombinding-but-not-when-using-nettcpbi/6720923#6720923

hope this helps!

I could be wrong but could you try using ( var discoveryClient = new DiscoveryClient(new UdpDiscoveryEndpoint()) ) { var findCriteria = new FindCriteria(typeof(IDiscoverableService)) { Duration = TimeSpan.FromSeconds(1) }; discoveryClient.Find(findCriteria); discoveryClient.Close(); }

How about bringing out the big guns: procdump from sysinternals to make a dump, and windbg with the psscor4 extensions to show you where the memory has gone. ( with !dumpheap -stat )

Really strange, the second example levels out at 210MB on my box (Vista 64bit), with no config of WCF whatsoever.

This may be simplistic, but is the "discoveryClient.Find(findCriteria)" method disposing of its results after returning?

Maybe it's a debugger interaction. running the sample outside of the debugger got me these results with a debugger attached i got 209 for all the results.

Before collect:209,000 After collect:40,000 After finalizers:40,000

so select isn't broken. the debugger is?

full code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.ServiceModel.Discovery;
using System.ServiceModel;

namespace ConsoleApplication1
{
    class Program
    { 
        static void Main(string[] args)
        {
            int count = 150;
            var countdown = new CountdownEvent(count);

            for (int i = 0; i < count; i++)
            {
                var discoveryClient = new DiscoveryClient(new UdpDiscoveryEndpoint()); 
                var findCriteria = new FindCriteria(typeof(IDiscoverableService))
                {
                };
                discoveryClient.FindProgressChanged += (sender, eventArgs) => { }; // do nothing
                discoveryClient.FindCompleted += (sender, eventArgs) =>
                {
                    using (discoveryClient)
                        discoveryClient.Close();

                    PrintMemory(countdown.CurrentCount.ToString());
                    countdown.Signal();
                };
                discoveryClient.FindAsync(findCriteria);
            }

            countdown.Wait();

            PrintMemory("Before collect");
            GC.Collect();
            PrintMemory("After collect");
            GC.WaitForPendingFinalizers();
            PrintMemory("After finalizers");
            Console.ReadKey(); 
        }

        private static void PrintMemory(string p)
        {
            Console.WriteLine("{0}:{1:N3}", p, Environment.WorkingSet / (1024 * 1024));
        }
    }
    [ServiceContract]
    public interface IDiscoverableService
    {
        [OperationContract]
        void dosomething();
    }
}

It gets weirder, the results aren't consistent.

only if I add this bit of code before the console.readkey I get a consistent drop of memory usage to about 40 MB

        Thread.Sleep(60000);
        PrintMemory("After sleep");
        GC.Collect();
        PrintMemory("After collect 2 ");
        GC.WaitForPendingFinalizers();
        PrintMemory("After finalizers 2");
        Console.ReadKey();

So my guess there's something fishy going on in the unmanaged world.

Last spam of the day, just edited the full repro to include an extra sleep of 60 seconds. Verdict: Select isn't broken, it's garbage collector is slow ;-)

Ah yes, well, can't help you there. apparently 640K is not enough for even 1 discoveryclient.

Maybe it behaves better memorywise if just 1 discovery client with multiple async discoveries in flight is used instead of a whole bunch of clients? I am unfamiliar with System.ServiceModel.Discovery so I'm just guessing here.

It's probably the Binding buffer configuration.

Using the below UdpDiscoveryEndpoint configuration for both service and client there is substantially less memory usage (from 170MB to 67MB maximum working set). Also, discovery is slower.

        var endpoint = new UdpDiscoveryEndpoint();
        var binding = (CustomBinding)endpoint.Binding;
        var element = binding.Elements.OfType<TransportBindingElement>().First();
        element.MaxBufferPoolSize = ushort.MaxValue;
        element.MaxReceivedMessageSize = ushort.MaxValue / 4;
        return endpoint;

Just FYI, the post looks all funny in Google Reader, apparently doubly-encoded.

Just looked through the System.ServiceModel.Discovery assembly using reflector and the Find method on DiscoveryClient instantiates a SyncOperationState object which internally contains ManualResetEvent.

SyncOperationState class is internal but not disposable, and I cannot see anywhere that the ManualResetEvent is closed or disposed.

I suppose the GC will eventually get around to collecting this but would definitely contribute to the excessive memory