[Mono-dev] Top again

[Jeremiah Gowdy]

Has Xamarin considered offering professional support plans for the other major consumer of Mono, those of us who want to use C# to develop our service applications but would prefer to host them on Linux for obvious reasons?

As a representative of one of the aforementioned companies who is trying to run production services on Mono+Linux, I'm concerned that we're building a model that's dependent on a runtime supported by a company which is focused on mobile naturally because that's where the revenue is.  Unfortunately, we have no way to change that.  If Xamarin were to offer support for enterprises, perhaps we could become a larger part of the overall revenue stream and our bugs would get better prioritization.

I don't think this would be bad for the project, since the classes our applications rely on are the core classes of .NET.  Nothing fancy, just Sockets, Threads, collections, etc.

The bugs we've experienced are:

The Socket.Send and Socket.BeginSend in blocking mode returning without finishing the entire send, which we had to fix in our code by not using async and looping on blocking Send() until the entire send is actually complete.  Work that by spec should be done by Send and BeginSend.  It works, but it's Mono-specific and/or Linux-specific hacks that aren't needed on Windows+CLR.

Mono's BlockingCollection<T> performance as a producer consumer queue for a pool of threads is really really bad.  As the number of threads waiting on the collection goes up, the thrashing rapidly gets out of control.  There is no such issue on Windows+CLR.  I ended up copying Mono's BlockingCollection.cs, copying it into my project as MonoBlockingCollection.cs and rewriting parts of it to make the performance reasonable.  We finally changed the design of the service so we could remove the custom class, and it works fine that way, but our goal is to minimize or eliminate any Mono specific changes to our code because we aren't yet convinced that the project considers service applications a first class consumer of the platform.

We have to choose between running Boehm GC and hitting too many roots failures, or running sgen and getting crashes due to bugs.  We are constantly testing running our application on different nodes in either mode in the hopes that one will prove more stability than the other.  We have also had to modify our code significantly in ways that seem less likely to reproduce either crash.

Now we are certainly a fault here too.  The send bug is reported in bug 3844, but we don't have a test case that reproduces it.  It's difficult to reproduce, because it happens under load, in a multithreaded socket server.  But it seems like it would be very easy to add a check if we're in blocking mode and if Send doesn't honor the spec, loop until we're done sending so that consumers get expected behavior.  I should write that patch and submit it.  I'm pretty sure I haven't written a bug for the BlockingCollection<T> performance issue, nor have I submitted my improved version.  I'm capable of contributing to Mono, and I should do so since it's relevant to my interests and business.

That being said, giving companies with different business models a way to contribute to the bottom line and thus get more attention for their needs seems like it would help everyone.  Considering what Mono saves us on administrative overhead and licensing costs, there's no reason my business and other businesses wouldn't consider such a support agreement if it had value.


I love this project, and want to see it succeed in more than just mobile.  Thanks!

From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Greg Young
Sent: Wednesday, May 29, 2013 9:09 AM
To: mono-devel-list at lists.ximian.com
Subject: [Mono-dev] Top again

So we have reproduced bugs even with suggestions given (and documented)

How do we move forward from this point? We have shown in the past that we don't mind bounties but we are at a point of giving up and saying mono is not acceptable as a server platform. The issues we have will affect anyone who wants to build a tcp server.

How can we move forward? We have provided failing cases. We have provided a fix that has a theoretical deadlock (never actually happened in billions of tests).

I understand that the core business has moved and tcp servers are not common with mobile devices but really? I would expect this kind of issue to be a top priority.

Greg


--
Le doute n'est pas une condition agréable, mais la certitude est absurde.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130529/09abab55/attachment-0001.html>