I've had some strangeness with the thread pool in the past, but never enough to get a solid, consistent repro that I could file a bug for. I don't know if this is related or not, but I've actually seen a simple Timer fail to generate callbacks under very high load (and on old hardware). Again, not repro-able enough to file a bug for but enough to make me nervous.<div>
<br></div><div>When I run your mono-socket-problem code, I start seeing the "No completion callback" messages within 5 seconds and then regularly every 5-10 seconds or so. I can't say for sure if the issues are related, but if they are, this is the best repro I've seen.<div>
<br></div><div>As you can imagine, I've grown a bit of a distrust for the threadpool and thus async socket operations. I put some effort into digging through the mono internals, but without a solid repro and lacking a good understanding of the thread pool implementation, my ultimate solution was to give up and stop using async sockets altogether.</div>
<div><br></div><div>I took a different approach: I wrapped libev and POSIX sockets. Manos de Mono is an excellent example of this approach. So far, this has been rock solid and performs extremely well. Of course, the major downsides are: 1) it's platform-specific, and 2) totally single-threaded. I get around #2 by simply running multiple load-balanced nodes, one for each core. I still make light use of the thread pool for long-running operations that shouldn't block the message loop.</div>
<div><br></div><div>I only throw this out there as a possible alternative if you don't have any success resolving this issue. Our architecture fit very well into the event loop paradigm, but that may not work for everyone.<br>
<div><br><div class="gmail_quote">On Tue, Jul 17, 2012 at 7:47 AM, Greg Young <span dir="ltr"><<a href="mailto:gregoryyoung1@gmail.com" target="_blank">gregoryyoung1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Btw to avoid confusion and duplicated work if someone starts could we just sync a bit in this thread? <span></span><br><br>On Tuesday, July 17, 2012, Greg Young  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hey all.<div><br></div><div>As this is a big issue for us and I feel a huge problem for mono in general at this point as it means sockets basically dont work which is a strong point of unix environments, I would like to propose something I have done in the past. I am willing to offer a bounty (personally) for a working fix to this section of code of $500 usd (more if done quickly). </div>


<div><br></div><div>Acceptance criteria is the included test working in a stable fashion in Linux / bsd but just Linux is acceptable as well,</div><div><br></div><div>I honestly wish more people would do this kind of thing with OSS projects.</div>


<div><br></div><div>Cheers,</div><div><br></div><div>Greg<span></span><br><br>On Saturday, July 7, 2012, Yuriy Solodkyy  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Hi Rodrigo,<br>
<br>
please find a small sample app at <a href="https://github.com/ysw/mono-socket-problem" target="_blank">https://github.com/ysw/mono-socket-problem</a><br>
<br>
This app can start in either server or client mode.  These modes only<br>
differ in whether it listens for connections on multiple ports or<br>
connects to server on multiple ports. Upon connecting to or accepting<br>
connection it immediately sends some data, and then sends next chunk<br>
of data in response to any data received from the other side.  There<br>
are some random delays in code and we limit outgoing traffic on each<br>
connection not to be significantly higher than inbound.<br>
<br>
There is also a separate thread which regularly checks status of every<br>
connection and report any connections that are awaiting a callback,<br>
but their status obtained with socket.poll is already READY.  (A<br>
several seconds delay is still allowed).<br>
<br>
See also the README file.<br>
<br>
<br>
Also, it seems that constantly changing men/max threads in ThreadPool<br>
increases probability of the problem. See code.<br>
Please let me know if this sample app works for you.<br>
<br>
Hope it helps<br>
<br>
<br>
Thank you,<br>
Yuriy<br>
<br>
<br>
We've been aware of such issues, could you file a bug and attach a test<br>
case with it please?<br>
<br>
This would really really help us fix it.<br>
<br>
On Wed, Jun 27, 2012 at 4:08 AM, Greg Young <gregoryyoung1 at <a href="http://gmail.com" target="_blank">gmail.com</a>> wrote:<br>
<br>
> We are experiencing an issue with async behaviours in sockets (with<br>
> SendAsync/callback not Begin/End).<br>
><br>
> Our visible issue is that when in a send loop we will fail on our<br>
> heartbeats. After debugging and counting calls into/out of<br>
> SendAsync/callback we see that we are inside of a call to SendAsync<br>
> (eg: it never returns, in our case for 10 seconds before we declare<br>
> the socket dead). We can duplicate this fairly regularly on<br>
> mac/bsd/linux though its nonconsistent (sometimes it may happen<br>
> repeatedly other times it works fine). The code does not have such<br>
> issues on MS CLR. We are also running on loopback so its unlikely that<br>
> an underlying network problem is causing the hang up. The code itself<br>
> is fairly straight forward (not that different than the MS example of<br>
> the API except that its fully async (separate send/receive loops while<br>
> the example is request/response))<br>
><br>
> I am pulling sources now to build latest but does anyone happen to<br>
> know of known issues with this sort of thing?<br>
><br>
> Cheers,<br>
><br>
> Greg<br>
><br>
> --<br>
> Le doute n'est pas une condition agréable, mais la certitude est absurde.<br>
> _______________________________________________<br>
> Mono-devel-list mailing list<br>
> Mono-devel-list at <a href="http://lists.ximian.com" target="_blank">lists.ximian.com</a><br>
> <a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
><br>
<br>
--<br>
Yuriy Solodkyy<br>
(<a>y.solodkyy@gmail.com</a>)<br>
_______________________________________________<br>
Mono-devel-list mailing list<br>
<a>Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
</blockquote></div><br><span class="HOEnZb"><font color="#888888"><br>-- <br>Le doute n'est pas une condition agréable, mais la certitude est absurde.<br>
</font></span></blockquote><span class="HOEnZb"><font color="#888888"><br><br>-- <br>Le doute n'est pas une condition agréable, mais la certitude est absurde.<br>
</font></span><br>_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
<br></blockquote></div><br></div></div></div>