[Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Nikita Tsukanov
keks9n at gmail.com
Tue Aug 6 16:42:50 UTC 2013
Hello. I've written a simple SCGI server, configured nginx to work with it,
hammered it with jmeter and... got the same issue. It works for a while and
then stops accepting new connections (some existing ones still waiting with
CLOSE_WAIT). I get it with new NetworkStream(TcpListener.AcceptSocket())
and BeginWrite/BeginRead. MONO_DISABLE_AIO actually helps it to survive for
20-30 more seconds but result is the same.
Now I'll try to use some alternative way of working with sockets, may be
libuv or something like that.
Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30 21:08:00
UTC 2013)
2013/8/5 Alfred Hall <ahall at ahall.org>
> **
> Getting similar issues when using FastCGI/XSP proxied via Nginx using tcp
> and unix sockets (tried both). After hammering it with jmeter it ends up
> locking up. I'm wondering if other mono webapps have this issue. Would be
> useful if someone else here could do a similar loadtest using jmeter and
> let me know if it happens to them.
>
> -----Original message-----
> *From:* Alfred Hall <ahall at ahall.org>
> *Sent:* Sunday 4th August 2013 17:41
> *To:* Nikita Tsukanov <keks9n at gmail.com>; mono-devel-list at lists.ximian.com
> *Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up
> on linux
>
> Hi Nikita.
>
> Full thread dump:
>
> "<threadpool thread>" tid=0x0x7fc4ad29d700 this=0x0x7fc4ad584c70 thread
> handle 0x80f state : not waiting owns ()
>
>
> "IO Threadpool worker" tid=0x0x7fc4ad25c700 this=0x0x7fc4ad584dd0 thread
> handle 0x810 state : interrupted state owns ()
>
>
> "IO Threadpool worker" tid=0x0x7fc4a7567700 this=0x0x7fc4a741d350 thread
> handle 0x845 state : interrupted state owns ()
>
>
> "Threadpool worker" tid=0x0x7fc4ac39a700 this=0x0x7fc4a6192270 thread
> handle 0x837 state : interrupted state owns ()
> at <unknown> <0xffffffff>
> at (wrapper managed-to-native)
> object.__icall_wrapper_mono_gc_alloc_vector (intptr,intptr,intptr)
> <0xffffffff>
> at (wrapper alloc) object.AllocVector (intptr,intptr) <0xffffffff>
> at System.Net.HttpConnection.BeginReadRequest () <0x0003a>
> at System.Net.EndPointListener.OnAccept (object,System.EventArgs)
> <0x00357>
> at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted
> (System.Net.Sockets.SocketAsyncEventArgs) <0x0002e>
> at System.Net.Sockets.SocketAsyncEventArgs.AcceptCallback
> (System.IAsyncResult) <0x00336>
> at System.Net.Sockets.SocketAsyncEventArgs.DispatcherCB
> (System.IAsyncResult) <0x0010f>
> at (wrapper runtime-invoke) <Module>.runtime_invoke_void__this___object
> (object,intptr,intptr,intptr) <0xffffffff>
>
>
> I then tried the same again and only got this in my trace:
>
> Full thread dump:
>
> "<threadpool thread>" tid=0x0x7f31b8ac5700 this=0x0x7f31b8da4c70 thread
> handle 0x80e state : not waiting owns ()
>
>
> "IO Threadpool worker" tid=0x0x7f31b8a84700 this=0x0x7f31b8da4dd0 thread
> handle 0x80f state : interrupted state owns ()
>
> Not sure why I'm not getting any dump here. Any more debugging I can do on
> there?
>
> What seems to happen is its coping well initially with the requests and
> then in all of a sudden it stops accepting connections and existing
> connections dont die off.
>
> Cheers,
> Alf
>
> -----Original message-----
> *From:* Nikita Tsukanov <keks9n at gmail.com>
> *Sent:* Sunday 4th August 2013 16:13
> *To:* mono-devel-list at lists.ximian.com
> *Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up
> on linux
>
> Alfred, please, try to send SIGQUIT to mono (i. e. kill -SIGQUIT {PID})
> when it stops processing requests. It will force mono to write thread stack
> traces to stdout. Grab them and post here, I suspect that the issue is
> simular to one experienced by me.
>
>
> 2013/8/4 Nikita Tsukanov <keks9n at gmail.com>
>
>> Alfred, please, try to send SIGQUIT to mono (i. e. kill -SIGQUIT
>> {PID}) when it stops processing requests. It will force mono to write
>> thread stack traces to stdout. Grab them and post here, I suspect that
>> the issue is simular to one experienced by me.
>>
>
> _______________________________________________
>
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
> _______________________________________________
>
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> 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/20130806/66c3e664/attachment.html>
More information about the Mono-devel-list
mailing list