[Mono-list] Async sockets and memory leaks in BeginSend

xplicit svg at ngs.ru
Mon May 21 20:51:06 UTC 2012


I am developing server with mono using async socket model. Currently it's
about 500 simultaneously working clients with 20-100 operations per seconds.
The code should send messages accordingly theirs creation time, so I use
such pattern:

Send()
{
    //Dequeue message from queue. Messages placed in the queue accordingly
theirs creation time     
    SendStateObject state=new SendStateObject();
    state.buffer=Dequeue();  
    state.socket=client;
    
    //some checks in the code were removed, this function is called only
when no other send callbacks were ran
    client.BeginSend(state.buffer, 0, state.buffer.Length, SocketFlags.None,
new AsyncCallback(SendCallback), state);

} 

private void SendCallback(IAsyncResult ar)
{
    SendStateObject sendState = (SendStateObject)ar.AsyncState;
    Socket client = sendState.workSocket;

    try
    {
          client.EndSend(ar);
    }
    catch() /*Some exceptions handling */
    {}
    finally
    {
          sendState.buffer=null;
          sendState.workSocket=null;
    }

    if (SomeItemsInQueue()) Send();

}

And this code produces huge memory leaks under high load. Profiler says,
that there are millions of AsyncCallback objects and
System.Net.Sockets.SocketAsyncResult objects. 

I think, I could minimize number of AsyncCallback objects by creating it
only one time in constructor and passing it to BeginSend (I'll check it
later), but what to do with SocketAsyncResult (and byte buffers which it
contains in)? 
I don't create this object, it's created inside of BeginSend and in most
cases it is not claimed by garbage collector. 

Maybe I use wrong pattern and must remove calling Send() from the end line
of callback, but I don't understand, why these objects could not be freed by
GC...  



--
View this message in context: http://mono.1490590.n4.nabble.com/Async-sockets-and-memory-leaks-in-BeginSend-tp4648844.html
Sent from the Mono - General mailing list archive at Nabble.com.


More information about the Mono-list mailing list