[Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

[Yuriy Solodkyy]

Nikita,

just interesting if it is the same issue.  Have you tried applying this
patch https://github.com/mono/mono/pull/703/ ?

Make sure you DO NOT set MONO_DISABLE_AIO  as only epoll/kqueue backend is
patched there.

Not sure if it is related, though.

thank you
-yuriy


On Tue, Aug 6, 2013 at 7:42 PM, Nikita Tsukanov <keks9n at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>


-- 
Yuriy Solodkyy
(y.solodkyy at gmail.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130806/5b3cb3e1/attachment-0001.html>