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
: Connections leaking in FastCgi when hosted on TCP socket
Status: NEW
Product: Class Libraries
Classification: Mono
Component: Sys.Web
: Trunk
: PC Linux
: --- normal
: ---
Assigned To: Bugzilla
:
:
:
:
  Show dependency treegraph
 
Reported: 2012-08-24 18:25 EDT by pgentoo
Modified: 2012-08-25 06:34 EDT (History)
2 users (show)

See Also:
Tags:
Test Case URL:
External Submit: ---


Attachments

Description pgentoo 2012-08-24 18:25:20 EDT
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.