[Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Nikita Tsukanov
keks9n at gmail.com
Mon Aug 12 19:44:46 UTC 2013
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 <keks9n at 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" <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/20130812/b7c0cde8/attachment-0001.html>
More information about the Mono-devel-list
mailing list