/usr/bin/mono ./bin/xsp2fastcgi.exe /address=10.252.5.188 /socket=tcp:1234 /maxconns=1024 /maxreqs=1024 /applications=/:. /stoppable=False /automappaths=True /root=/nuxleus/Web/Development &

… and it definitely doesn’t help things along. If I remove /automappaths and /root and restart the application everything seems just fine.

Not a big concern for me at the moment, but if you happen to think of any reasons why this could be happening I’d definitely be interested in helping to get to the bottom of this such that other folks can avoid any frustrations.

Thanks, Brian!


/usr/bin/mono ./bin/xsp2fastcgi.exe /address=10.252.5.188 /socket=tcp:1234 /maxconns=1024 /maxreqs=1024 /applications=/:. /verbose
xsp2fastcgi
Listening on port: 10.252.5.188
Listening on address: 1234
Adding applications '/:.'...
Registering application:
Host: any
Port: any
Virtual path: /
Physical path: /nuxleus/Web/Development
Root directory: /nuxleus/Web/Development
Max connections: 1024
Max requests: 1024
Multiplex connections: False
Use /stopable=True to enable stopping from the console.


The same web application using the fastcgi-mono-server2.exe assembly,


fastcgi-mono-server2 /address=10.252.5.188 /socket=tcp:1234 /maxconns=1024 /maxreqs=1024 /applications=/:. /verbose
fastcgi-mono-server2
Listening on port: 10.252.5.188
Listening on address: 1234
Adding applications '/:.'...
Registering application:
Host: any
Port: any
Virtual path: /
Physical path: /nuxleus/Web/Development
Root directory: /nuxleus/Web/Development
Max connections: 1024
Max requests: 1024
Multiplex connections: False
Use /stopable=True to enable stopping from the console.
Registering application:
Host: any
Port: any
Virtual path: /
Physical path: /nuxleus/Web/Development/
Registering application:
Host: any
Port: any
Virtual path: /
Physical path: /nuxleus/Web/Development/


As per the multiple applications being registered, and via watching the process via top, it’s definitely restarting itself with each request. Any ideas as to why that might be (the VS.NET compiled assembly works the way it should)? For reference, you can find the VS.NET compiled assembly inside http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Dependencies/

via top,

21396 root 15 0 183m 92m 39m S 99.9 1.2 1:07.17 mono

via ps aux,

root 21396 106 1.2 187788 94476 ? Sl 20:13 2:01 /usr/bin/mono /usr/lib/fastcgi-mono-server/fastcgi-mono-server2.exe

This is on a four processor machine so I hadn’t noticed the processor peg until now. I’ll run things standalone and see what I can come up with.

Also, worth noting, I ran into this same problem a while back, the fix of which came in the form of compiling the assembly via VS.NET. Assuming it was a problem with the CIL generated from gmcs I set it aside as a problem to dig deeper into as time allowed. The problem resurfaced recently when I fired up a new machine and found that for some reason the fastcgi-mono process wasn’t returning anything back to the lighttpd, so lighttpd just sat there waiting. This was using TCP instead of a Unix socket, so I thought I would try using Unix sockets again to see if that might fix the problem. The current issue at hand is the result.

For comparison to the above, I still have the VS.NET compiled assembly running on TCP port 1234,

root 6566 0.0 0.2 33980 17476 ? Sl Oct04 0:01 /usr/bin/mono /nuxleus/src/Dependencies/xsp2fastcgi.exe /address=127.0.0.1 /socket=tcp:1234 /maxco (snipped off by the console)

I’ll run the process via the console and see if that gives any further clues as to what’s going on.

Also, in answer to your question as to whether the process is being killed off and respawned by lighttpd, it doesn’t look like it. I wonder if the response time is related to the fact that the processor is pegged?

That sort of behavior is most likely associated with the FastCGI server crashing after the page has been loaded, or perhaps the web server losing track of the FastCGI server and spawning a new one. The first thing I would check is `top’ or a similar program to see if the FastCGI server stops running or if multiple instances appear. After that, running the server from the console or with additional debugging parameters set.

Thanks for the advice! Will dig into this now and report back.

Also, what web server are you running on?

lighttpd

Also, what web server are you running on?

I’ve run into a bug that I thought I would quickly run by you.

If you access > http://dev.amp.fm/service/search/default.asmx?wsdl and compare the speed in which it returns a response with > http://dev.amp.fm:8080/service/search/default.asmx?wsdl (which is just xsp2 running standalone) you’ll notice that the application seemingly recompiles itself with each request on the first. Any ideas as to why this might be?