Hello. I've reproduced the problem without ANY I/O only with NancyFx. Following code leads to lock up:
class MainClass { public static void Main(string[] args) { var bt = new DefaultNancyBootstrapper (); bt.Initialise (); var engine = bt.GetEngine (); int rid = 0; while (true) { var crid = rid++; ThreadPool.QueueUserWorkItem (_ => { var resp = engine.HandleRequest ( new Request ("GET", "/", new Dictionary<string, IEnumerable<string>> (), RequestStream. FromStream (new MemoryStream (), 0, 0), "http", "", "127.0.0.1")); resp.Response.Contents (new MemoryStream ()); Console.WriteLine("Request #{0} done ", crid); }); Console.WriteLine("Request #{0} added", crid ); } } } public class TestController : NancyModule { public TestController () { Get ["/"] = _ => "test"; } } It works fine with mono 2.10.8 from Ubuntu repos. 2013/8/8 Nikita Tsukanov <kek...@gmail.com> > I'm unable to reproduce the issue with HttpListener/Sockets alone. It > needs INancyEngine.ProcessReqiest() somewhere in request processing > pipeline. So I'm still investigating, what conditions are needed to > repoduce the bug (and I suspect that it doesn't have to do with I/O at all, > since it reproduces even with my hand-made send/recv sockets backend). > > > 2013/8/7 "Andrés G. Aragoneses" <kno...@gmail.com> > >> If you're able to reproduce it with 3.3 and not with 2.10.x, you should >> definitely open a bug report for it in http://bugzilla.xamarin.com/stating >> "[regression]" in the bug summary. >> >> Also, I would open a separate bug report for the segfault you're getting >> when running with MONO_DISABLE_AIO (pasting the backtrace of the segfault, >> with debug symbols installed). >> >> >> On 07/08/13 14:02, Alfred Hall wrote: >> >>> Tried running it with sgen or boehm on 2.10? Worth trying both I think. >>> Also how about 3.3 (master) ? >>> >>> -----Original message----- >>> *From:* Nikita Tsukanov <kek...@gmail.com> >>> *Sent:* Wednesday 7th August 2013 12:54 >>> *To:* >>> mono-devel-list@lists.ximian.**com<mono-devel-list@lists.ximian.com> >>> *Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) >>> >>> locking up on linux >>> >>> I've rewritten my SCGI server to work with TPL directly instead of >>> using async/await to make it run on mono 2.10. Then I've tried to >>> run it with mono 2.10.8.1 and mono 3.2 with System.Net.Sockets >>> backend and to hammer it with jmeter. 500K requests without any >>> lockups on Mono 2.10, lockup at 22164th request on mono 3.2. >>> >>> Server source code is still on GitHub - >>> >>> https://github.com/kekekeks/**scgi-sharp<https://github.com/kekekeks/scgi-sharp> >>> >>> >>> 2013/8/7 Greg Young <gregoryyou...@gmail.com >>> <mailto:gregoryyoung1@gmail.**com <gregoryyou...@gmail.com>>> >>> >>> >>> I believe attaching a debugger changes things like optimizations >>> from occurring (not positive but it does in clr) >>> >>> >>> On Wednesday, August 7, 2013, Nikita Tsukanov wrote: >>> >>> Huh, it doesn't require debugger to be _attched_, just >>> debugging subsystem initialized i. e. if I launch this >>> program as a "debugger" it doesn't lock up. >>> >>> publicstaticvoidMain(string[]**args) >>> { >>> intport=27042; >>> if(args.Length !=0) >>> port=int.Parse(args[0]); >>> while(true) >>> { >>> varvm= Mono.Debugger.Soft.**VirtualMachineManager.Listen(** >>> newIPEndPoint(IPAddress.**Loopback,port)); >>> vm.Resume(); >>> vm.Detach(); >>> } >>> } >>> >>> I'll use running with >>> --debugger-agent=transport=dt_**socket,address= >>> 127.0.0.1:27042 >>> <http://127.0.0.1:27042> as a temporary workaround since >>> >>> performance doesn't degrade a lot. >>> >>> >>> 2013/8/7 Nikita Tsukanov <kek...@gmail.com> >>> >>> I suspect that the problem is actually with thread pool >>> itself. I've created socket layer implementation using >>> libevent (wrapped with Oars) and send/recv that utilizes >>> thread pool for cases when it's unable to complete >>> operation synchronously. It survives longer, but still >>> locks up after a while. Same behavior with debugger - >>> I'm unable to reproduce the issue when running under it. >>> I also unable to grab thread stack traces, it prints >>> "Full thread dump: " and nothing else. >>> >>> >>> 2013/8/7 Greg Young <gregoryyou...@gmail.com> >>> >>> We will see your test then as it will probably >>> affect us as well >>> >>> >>> On Tuesday, August 6, 2013, Nikita Tsukanov wrote: >>> >>> Greg, I've tried running my server with mono >>> compiled from master (with pull request #703 >>> merged in), still freezes after a while. >>> >>> >>> 2013/8/7 Greg Young <gregoryyou...@gmail.com> >>> >>> Do you have our pull req? We are stable >>> after (and seriously read history of this >>> list) >>> >>> >>> On Tuesday, August 6, 2013, Nikita Tsukanov >>> wrote: >>> >>> >>> https://github.com/kekekeks/**scgi-sharp<https://github.com/kekekeks/scgi-sharp>- >>> here is my SCGI server with host for >>> NancyFx. If you run Sandbox.exe with >>> --echo-server it will not use nancy >>> infrastructure and will respond >>> directly. It locks up after several >>> thousands of requests under jmeter. >>> >>> Simple nginx configuration: >>> >>> location / >>> { >>> include /etc/nginx/scgi_params; >>> scgi_pass 127.0.0.1:10081 >>> <http://127.0.0.1:10081>; >>> >>> } >>> >>> Now I'm looking for alternative socket >>> library to use it as a replacement for >>> System.Net.Sockets. >>> >>> >>> 2013/8/6 Greg Young >>> <gregoryyou...@gmail.com> >>> >>> Actually not that surprised we also >>> found out file stream.flush(true) >>> only works sometimes and ms never >>> back supported it to actually work :) >>> >>> >>> On Tuesday, August 6, 2013, Alfred >>> Hall wrote: >>> >>> __ >>> >>> Yeah you're having exactly the >>> same issues as I am. I'm >>> surprised others haven't had >>> this problem before. Not sure >>> who works on this area of the >>> mono codebase these days. If you >>> got a minimal test case it may >>> be worth us raising a Xamarin >>> bug in bugzilla. >>> >>> -----Original message----- >>> *From:* Nikita >>> Tsukanov <kek...@gmail.com> >>> *Sent:* Tuesday 6th August >>> 2013 20:18 >>> *To:* >>> >>> mono-devel-list@lists.ximian.**com <mono-devel-list@lists.ximian.com> >>> *Subject:* Re: [Mono-dev] >>> >>> NancyFX self hosting >>> (HttpListener) locking up on >>> linux >>> >>> Running with mono from >>> master haven't helped. >>> >>> And I'm not sure what the >>> hell is going on, but I >>> cann't reproduce the issue >>> when running under... >>> Monodevelop's debugger. It >>> runs perfectly under it, but >>> when I try to run the same >>> binary from console (even >>> with --debug option) it >>> locks up or segfaults. Does >>> anyone know what does it >>> mean? >>> >>> >>> 2013/8/6 Nikita Tsukanov >>> <kek...@gmail.com> >>> >>> Great. It locked up with >>> my more complex logic. >>> Funny fact: NancyFx >>> increases request >>> processing time from 2ms >>> to 70ms with the same >>> echo response. >>> Another funny fact: with >>> MONO_DISABLE_AIO I've >>> got segfault. >>> >>> Now I'll try to use >>> build patched mono. Not >>> sure that it's the same >>> issue, because in my >>> case it never tries to >>> read and write simultane >>> >>> >>> >>> -- >>> Le doute n'est pas une condition agréable, mais la certitude est >>> absurde. >>> >>> >>> ______________________________**_________________ >>> >>> Mono-devel-list mailing list >>> >>> Mono-devel-list@lists.ximian.**com<Mono-devel-list@lists.ximian.com> >>> >>> >>> http://lists.ximian.com/**mailman/listinfo/mono-devel-**list<http://lists.ximian.com/mailman/listinfo/mono-devel-list> >>> >>> >>> >>> ______________________________**_________________ >>> Mono-devel-list mailing list >>> Mono-devel-list@lists.ximian.**com <Mono-devel-list@lists.ximian.com> >>> http://lists.ximian.com/**mailman/listinfo/mono-devel-**list<http://lists.ximian.com/mailman/listinfo/mono-devel-list> >>> >>> >> >> ______________________________**_________________ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.**com <Mono-devel-list@lists.ximian.com> >> http://lists.ximian.com/**mailman/listinfo/mono-devel-**list<http://lists.ximian.com/mailman/listinfo/mono-devel-list> >> > >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list