This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 6685 - Connections leaking in FastCgi when hosted on TCP socket
Summary: Connections leaking in FastCgi when hosted on TCP socket
Status: NEW
Alias: None
Product: Class Libraries
Classification: Mono
Component: Sys.Web (show other bugs)
Version: Trunk
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-08-24 18:25 UTC by pgentoo
Modified: 2012-08-25 06:34 UTC (History)
2 users (show)

See Also:
Tags:


Attachments

Description pgentoo 2012-08-24 18:25:20 UTC
Similar to https://bugzilla.xamarin.com/show_bug.cgi?id=3765, however 3765 only seems to resolve the issue if using a UNIX socket backed fastcgi process.  If using TCP, the problem remains.

I was able to repro this with creating a single page HelloWorld.aspx application, and holding down F5 in the browser to continuously refresh it.  

Running "lsof|grep mono|grep identify|wc -l", you'll see that the handle count will grow for broken socket connections like the following:

mono      28944 28958      nginx  338u     sock                0,6        0t0   17471206 can't identify protocol
mono      28944 28958      nginx  339u     sock                0,6        0t0   17473562 can't identify protocol
mono      28944 28958      nginx  340u     sock                0,6        0t0   17480635 can't identify protocol
mono      28944 28958      nginx  341u     sock                0,6        0t0   17473629 can't identify protocol
mono      28944 28958      nginx  342u     sock                0,6        0t0   17473639 can't identify protocol
mono      28944 28958      nginx  343u     sock                0,6        0t0   17473346 can't identify protocol
mono      28944 28958      nginx  344u     sock                0,6        0t0   17489879 can't identify protocol


Without 3765 (using packaged version of XSP 2.10) whether on a TCP or UNIX socket I experience this issue.  After moving to latest XSP trunk, and TCP socket issue remained.  Switching to unix socket resolved the issue, so it seems that maybe there is some parallel/similar code that needs to be handled for unix socket connection issues?

Result of this bug is the same as 3765, handles being exhausted and service failures occurring due to too many open files and/or memory usage/swapping.

Note You need to log in before you can comment on or make changes to this bug.