Hi Yuriv, in which environments can you reproduce it? I tried on OSX with mono 2.10 and 2.12 for half an hour each with no luck.<div><br><br><div class="gmail_quote">On Thu, Jul 19, 2012 at 3:55 AM, Yuriy Solodkyy <span dir="ltr"><<a href="mailto:yuriy@couldbedone.com" target="_blank">yuriy@couldbedone.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Brett,<br>
<br>
"No completion callback" is what proves the problem, unless there is a<br>
problem in the sample code itself.<br>
<br>
I tried to rebuild mono with thread/pool instead of epoll socket<br>
implementation and still get the same problem. So, I concluded it is<br>
not epoll specific problem.<br>
<span class="HOEnZb"><font color="#888888"><br>
-yuriy<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Jul 19, 2012 at 12:08 AM, Brett Ernst <<a href="mailto:brett.e.ernst@gmail.com">brett.e.ernst@gmail.com</a>> wrote:<br>
> I've had some strangeness with the thread pool in the past, but never enough<br>
> to get a solid, consistent repro that I could file a bug for. I don't know<br>
> if this is related or not, but I've actually seen a simple Timer fail to<br>
> generate callbacks under very high load (and on old hardware). Again, not<br>
> repro-able enough to file a bug for but enough to make me nervous.<br>
><br>
> When I run your mono-socket-problem code, I start seeing the "No completion<br>
> callback" messages within 5 seconds and then regularly every 5-10 seconds or<br>
> so. I can't say for sure if the issues are related, but if they are, this is<br>
> the best repro I've seen.<br>
><br>
> As you can imagine, I've grown a bit of a distrust for the threadpool and<br>
> thus async socket operations. I put some effort into digging through the<br>
> mono internals, but without a solid repro and lacking a good understanding<br>
> of the thread pool implementation, my ultimate solution was to give up and<br>
> stop using async sockets altogether.<br>
><br>
> I took a different approach: I wrapped libev and POSIX sockets. Manos de<br>
> Mono is an excellent example of this approach. So far, this has been rock<br>
> solid and performs extremely well. Of course, the major downsides are: 1)<br>
> it's platform-specific, and 2) totally single-threaded. I get around #2 by<br>
> simply running multiple load-balanced nodes, one for each core. I still make<br>
> light use of the thread pool for long-running operations that shouldn't<br>
> block the message loop.<br>
><br>
> I only throw this out there as a possible alternative if you don't have any<br>
> success resolving this issue. Our architecture fit very well into the event<br>
> loop paradigm, but that may not work for everyone.<br>
><br>
> On Tue, Jul 17, 2012 at 7:47 AM, Greg Young <<a href="mailto:gregoryyoung1@gmail.com">gregoryyoung1@gmail.com</a>> wrote:<br>
>><br>
>> Btw to avoid confusion and duplicated work if someone starts could we just<br>
>> sync a bit in this thread?<br>
>><br>
>> On Tuesday, July 17, 2012, Greg Young wrote:<br>
>>><br>
>>> Hey all.<br>
>>><br>
>>> As this is a big issue for us and I feel a huge problem for mono in<br>
>>> general at this point as it means sockets basically dont work which is a<br>
>>> strong point of unix environments, I would like to propose something I have<br>
>>> done in the past. I am willing to offer a bounty (personally) for a working<br>
>>> fix to this section of code of $500 usd (more if done quickly).<br>
>>><br>
>>> Acceptance criteria is the included test working in a stable fashion in<br>
>>> Linux / bsd but just Linux is acceptable as well,<br>
>>><br>
>>> I honestly wish more people would do this kind of thing with OSS<br>
>>> projects.<br>
>>><br>
>>> Cheers,<br>
>>><br>
>>> Greg<br>
>>><br>
>>> On Saturday, July 7, 2012, Yuriy Solodkyy wrote:<br>
>>>><br>
>>>> Hi Rodrigo,<br>
>>>><br>
>>>> please find a small sample app at<br>
>>>> <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>><br>
>>>> 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<br>
>>>> > 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 href="mailto:y.solodkyy@gmail.com">y.solodkyy@gmail.com</a>)<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>
>>><br>
>>><br>
>>> --<br>
>>> Le doute n'est pas une condition agréable, mais la certitude est absurde.<br>
>><br>
>><br>
>><br>
>> --<br>
>> Le doute n'est pas une condition agréable, mais la certitude est absurde.<br>
>><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>
><br>
><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>
<br>
<br>
<br>
--<br>
Yuriy Solodkyy<br>
(<a href="mailto:y.solodkyy@gmail.com">y.solodkyy@gmail.com</a>)<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>
</div></div></blockquote></div><br></div>