[Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Nikita Tsukanov
keks9n at gmail.com
Thu Aug 8 15:56:59 UTC 2013
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" <knocte at 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 <keks9n at gmail.com>
>> *Sent:* Wednesday 7th August 2013 12:54
>> *To:* mono-devel-list at lists.ximian.**com<mono-devel-list at 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 <gregoryyoung1 at gmail.com
>> <mailto:gregoryyoung1 at gmail.**com <gregoryyoung1 at 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 <keks9n at 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 <gregoryyoung1 at 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 <gregoryyoung1 at 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
>> <gregoryyoung1 at 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 <keks9n at gmail.com>
>> *Sent:* Tuesday 6th August
>> 2013 20:18
>> *To:*
>> mono-devel-list at lists.ximian.
>> **com <mono-devel-list at 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
>> <keks9n at 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 at lists.ximian.**com <Mono-devel-list at 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 at lists.ximian.**com <Mono-devel-list at 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 at lists.ximian.**com <Mono-devel-list at lists.ximian.com>
> http://lists.ximian.com/**mailman/listinfo/mono-devel-**list<http://lists.ximian.com/mailman/listinfo/mono-devel-list>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130808/0cc0ba02/attachment-0001.html>
More information about the Mono-devel-list
mailing list