Bug 2143 - EndReceive never called on TCP Socket
Summary: EndReceive never called on TCP Socket
Status: RESOLVED INVALID
Alias: None
Product: Runtime
Classification: Mono
Component: io-layer ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2011-11-21 18:06 UTC by Stephen Punak
Modified: 2012-10-29 19:59 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED INVALID

Description Stephen Punak 2011-11-21 18:06:45 UTC
We have a TCP server which handles thousands of transactions a second from persistent client connections.. 

It's an IPC server - a replacement for Microsoft Message Queues, and uses the asynchronous model (BeginReceive / EndReceive) 

Sometimes... VERY RARELY, EndReceive is never called, even though inbound data is present (tcpdump and wireshark verify this). So, the inbound data backs up until the sender is blocked by TCP on the client machine. This continues until there is any new I/O on the listener (e.g. a new incoming connection). At that point, all the data (which should have been received via EndReceive) pours in.

This is well-tested production code, and has been running on Windows (.Net) for a couple of years - we would like to move to Mono. 

Replicating this bug is very hard (one in hundreds of thousands of messages), and seems to be very timing dependent. Even adding very light debugging lines seems to alter the reproducability. 

This symptom is reproducable in mono 2.10.2-1, but i haven't been able to reproduce it on mono 2.10.5-1. However, I do notice that the socket seems to hang for a few seconds on 2.10.5-1, and at about the same frequency as the bug reproduces on 2.10.2-1. This leads me to believe that some change was made to alleviate the problem, although I can't find a bug report.

My main purpose in this report is to verify that a bug was found and fixed, and isn't still lurking around.
Comment 1 Rodrigo Kumpera 2012-10-29 19:59:47 UTC
Lots of stuff have been fixed since 2.10.2 and 2.10.5, try mono 3.0 and report back if you still have problems.