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
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
On 06/08/13 18:42, Nikita Tsukanov wrote:
Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30
21:08:00 UTC 2013)
Mono 3.2.0 does *not* have Yuri's patch.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
Interesting... I've written a simple server using only Socket.BeginRecieve
and Socket.BeginSend. It just reads 100 bytes and then sends hardcoded HTTP
response. Now jmeter is working for 5 minutes and it still responds with
Lorem ipsum ... perfectly. I'll try to port my SCGI server logic from
There are many cases the patch we provided does not affect eg no overlap in
io between send/receive
On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
Interesting... I've written a simple server using only Socket.BeginRecieve
and Socket.BeginSend. It just reads 100 bytes and then sends
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
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
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
I guess it means that it is a race condition which is not reproducible
inside the debugger (as the debugger slows things down).
On 06/08/13 21:18, Nikita Tsukanov wrote:
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
This has been going on for almost nine months look in list for tcp issues
which is why I'm curious that patch may not fix. It has with significant
(thousands of hours of testing) fixed problem for us. What os etc is being
run.
We have frankly also been surprised that this reported behaviour
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
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 /
{
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
Hi,
I download the latest tar file
(mono-3.2.1.tar.bz2http://download.mono-project.com/sources/mono/mono-3.2.1.tar.bz2)
and
followed the OS X build instructions. The 32 bit build is failing, similar
to this old thread
14 matches
Mail list logo