[Mono-bugs] [Bug 474217] New: Creating a remoting connection takes very long when a large number of clients connect simultaneously

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=474217


           Summary: Creating a remoting connection takes very long when a
                    large number of clients connect simultaneously
    Classification: Mono
           Product: Mono: Class Libraries
           Version: 2.2.x
          Platform: i686
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: System
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: sgroot at tkl.iis.u-tokyo.ac.jp
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---


User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64;
Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729;
Media Center PC 6.0)

When a large number of clients connect simutaneously to a .Net Remoting server
using the TCP channel, severe delays are experienced, sometimes as much as 20
seconds depending on the number of clients.

This issue is caused by the PoolGrowDelay in the
System.Runtime.Remoting.Channels.RemotingThreadPool class. The
System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.WaitForConnections()
method will accept a single connection and call the
RemotingThreadPool.RunThread method. In the case that there are no free threads
the RunThread method will wait for 500ms (PoolGrowDelay) and try again.

Because this 500ms wait is done inside the loop in the WaitForConnections
method, this prevents the server from accepting any more clients during this
time. All pending connections are forced to wait. Then after the time out
expires a new thread is created one more connection is accepted, the delay is
used again and all others have to wait once more. The delay accumulates rapidly
as the number of clients grows.

I have been able to work around my issue by removing the PoolGrowDelay. Latency
is critical in my application so I'd rather get a few unnecessary threads than
even a 500ms delay on any call.

Reproducible: Always

Steps to Reproduce:
1. Create an application using Remoting with the TcpServerChannel.
2. Have many (50+) clients connect to the server simultaneously.
Actual Results:  
Severe delays were encountered due to the PoolGrowDelay halting every single
pending connection.

Expected Results:  
I expected the PoolGrowDelay to affect only the current connection, and not
halt the WaitForConnections method. I would also prefer it if PoolGrowDelay was
configurable.

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.