<div dir="ltr"><div><div>'I love this project, and want to see it succeed in more than just mobile.'<br><br></div>I share these sentiments! :) <br><br>At first glance, this seems like a big opportunity. There is likely to be a lot of <a href="http://ASP.NET/WebAPI/socket">ASP.NET/WebAPI/socket</a> based enterprise server 
software currently running on IIS via MS-CLR where the company wants to get out of that expensive MSDN vendor lock-in to an open 
source solution, given several free/open source competitors (including some Apache/MIT licensed options). However, these companies seem to be more inclined to move to a JVM based solution, as there seems to be robust support for servers on that side of the fence, rather than simply porting their existing .net code to Mono.<br>
<br>Unfortunately, I've heard it said that paid support plans for open source projects have not had a great history of producing significant revenue - at least not at the levels needed to put some full-time engineers to it. You'd have to have people on it full-time, and have priority consideration for bugs/pull requests/etc... to make it worth paying for, at the very least. It's unclear how well the economics of it would play out in practice.<br>
<br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 29, 2013 at 1:03 PM, Rafael Teixeira <span dir="ltr"><<a href="mailto:monoman@gmail.com" target="_blank">monoman@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">'I love this project, and want to see it succeed in more than just mobile.'<br>
<br>
Very well said!<br>
<span class="HOEnZb"><font color="#888888">Rafael Teixeira<br>
O..:.)oooo<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, May 29, 2013 at 1:52 PM, Jeremiah Gowdy<br>
<<a href="mailto:jeremiah.gowdy@freedomvoice.com">jeremiah.gowdy@freedomvoice.com</a>> wrote:<br>
> Has Xamarin considered offering professional support plans for the other<br>
> major consumer of Mono, those of us who want to use C# to develop our<br>
> service applications but would prefer to host them on Linux for obvious<br>
> reasons?<br>
><br>
><br>
><br>
> As a representative of one of the aforementioned companies who is trying to<br>
> run production services on Mono+Linux, I’m concerned that we’re building a<br>
> model that’s dependent on a runtime supported by a company which is focused<br>
> on mobile naturally because that’s where the revenue is.  Unfortunately, we<br>
> have no way to change that.  If Xamarin were to offer support for<br>
> enterprises, perhaps we could become a larger part of the overall revenue<br>
> stream and our bugs would get better prioritization.<br>
><br>
><br>
><br>
> I don’t think this would be bad for the project, since the classes our<br>
> applications rely on are the core classes of .NET.  Nothing fancy, just<br>
> Sockets, Threads, collections, etc.<br>
><br>
><br>
><br>
> The bugs we’ve experienced are:<br>
><br>
><br>
><br>
> The Socket.Send and Socket.BeginSend in blocking mode returning without<br>
> finishing the entire send, which we had to fix in our code by not using<br>
> async and looping on blocking Send() until the entire send is actually<br>
> complete.  Work that by spec should be done by Send and BeginSend.  It<br>
> works, but it’s Mono-specific and/or Linux-specific hacks that aren’t needed<br>
> on Windows+CLR.<br>
><br>
><br>
><br>
> Mono’s BlockingCollection<T> performance as a producer consumer queue for a<br>
> pool of threads is really really bad.  As the number of threads waiting on<br>
> the collection goes up, the thrashing rapidly gets out of control.  There is<br>
> no such issue on Windows+CLR.  I ended up copying Mono’s<br>
> BlockingCollection.cs, copying it into my project as<br>
> MonoBlockingCollection.cs and rewriting parts of it to make the performance<br>
> reasonable.  We finally changed the design of the service so we could remove<br>
> the custom class, and it works fine that way, but our goal is to minimize or<br>
> eliminate any Mono specific changes to our code because we aren’t yet<br>
> convinced that the project considers service applications a first class<br>
> consumer of the platform.<br>
><br>
><br>
><br>
> We have to choose between running Boehm GC and hitting too many roots<br>
> failures, or running sgen and getting crashes due to bugs.  We are<br>
> constantly testing running our application on different nodes in either mode<br>
> in the hopes that one will prove more stability than the other.  We have<br>
> also had to modify our code significantly in ways that seem less likely to<br>
> reproduce either crash.<br>
><br>
><br>
><br>
> Now we are certainly a fault here too.  The send bug is reported in bug<br>
> 3844, but we don’t have a test case that reproduces it.  It’s difficult to<br>
> reproduce, because it happens under load, in a multithreaded socket server.<br>
> But it seems like it would be very easy to add a check if we’re in blocking<br>
> mode and if Send doesn’t honor the spec, loop until we’re done sending so<br>
> that consumers get expected behavior.  I should write that patch and submit<br>
> it.  I’m pretty sure I haven’t written a bug for the BlockingCollection<T><br>
> performance issue, nor have I submitted my improved version.  I’m capable of<br>
> contributing to Mono, and I should do so since it’s relevant to my interests<br>
> and business.<br>
><br>
><br>
><br>
> That being said, giving companies with different business models a way to<br>
> contribute to the bottom line and thus get more attention for their needs<br>
> seems like it would help everyone.  Considering what Mono saves us on<br>
> administrative overhead and licensing costs, there’s no reason my business<br>
> and other businesses wouldn’t consider such a support agreement if it had<br>
> value.<br>
><br>
><br>
><br>
><br>
><br>
> I love this project, and want to see it succeed in more than just mobile.<br>
> Thanks!<br>
><br>
><br>
><br>
> From: <a href="mailto:mono-devel-list-bounces@lists.ximian.com">mono-devel-list-bounces@lists.ximian.com</a><br>
> [mailto:<a href="mailto:mono-devel-list-bounces@lists.ximian.com">mono-devel-list-bounces@lists.ximian.com</a>] On Behalf Of Greg Young<br>
> Sent: Wednesday, May 29, 2013 9:09 AM<br>
> To: <a href="mailto:mono-devel-list@lists.ximian.com">mono-devel-list@lists.ximian.com</a><br>
> Subject: [Mono-dev] Top again<br>
><br>
><br>
><br>
> So we have reproduced bugs even with suggestions given (and documented)<br>
><br>
><br>
><br>
> How do we move forward from this point? We have shown in the past that we<br>
> don't mind bounties but we are at a point of giving up and saying mono is<br>
> not acceptable as a server platform. The issues we have will affect anyone<br>
> who wants to build a tcp server.<br>
><br>
><br>
><br>
> How can we move forward? We have provided failing cases. We have provided a<br>
> fix that has a theoretical deadlock (never actually happened in billions of<br>
> tests).<br>
><br>
><br>
><br>
> I understand that the core business has moved and tcp servers are not common<br>
> with mobile devices but really? I would expect this kind of issue to be a<br>
> top priority.<br>
><br>
><br>
><br>
> Greg<br>
><br>
><br>
><br>
> --<br>
> Le doute n'est pas une condition agréable, mais la certitude est absurde.<br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
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>