Programming · Summer of Code 2007

FastCGI ASP.NET Server Status Report 12

This is the final status report for the FastCGI ASP.NET Server. Due to a combination of a cold and schlepping around campus in 105F weather (40.6C where applicable), I’ve been a bit delirious. But not that my head is clearing, here’s the info you’ve been waiting for.

THIS WEEK’S ACCOMPLISHMENTS

The last week was a bit sparse on accomplishments. I had a lot of preparation to do to prep for the first week of school, and most problems have been resolved, but the following changes were made:

  • Application checking was reworked to verify that Web.Config also exists. As it stands, the application manager checks for both Web.Config and Bin when adding an application. Web.Config doesn’t necessarily mean something is an application, but the lack of it means that it isn’t. (I’ve been told this is a IIS rule.)
  • Requests that are directories but don’t end in a slash are redirected to the one with a slash.
  • Case insensitive checking is used for “Web.Config”, “Bin”, and index pages to improve compatibility.
  • Log levels can be set in the command line.
  • Log messages can be sent to the standard output.
  • ConfigurationManager.xml has been reorganized to group commands more logically.

WHERE IT STANDS NOW

At this point, the FastCGI Mono Server works completely with Lighttpd and Abyss, and when used with Apache and mod_fcgid, behaves like the default config supplied with mod_mono.

Cherokee has some problems when multiple requests are sent at the same time, but this may be a problem on either end. (In most cases, the mistake has been on my end.)

PLANS FOR THE FUTURE…

src/Mono.WebServer: Much of my work on Mono.WebServer is to be refactored and worked into Mono.WebServer (XSP package). This may mean automatic mapping support in mod_mono as well in the future.

src/Mono.WebServer.FastCgi: Most of the Mono.WebServer.FastCgi stuff will be restructured to and made more generic (think Mono.WebServer.CgiRequestWorker and Mono.WebServer.CgiApplicationHost) which will be reusable for things like SCGI support. This means fastcgi-mono-server may appear in XSP as well.

src/Mono.FastCgi: Support still needs to be finished for the Authorizer and Filter roles, and some renaming/FxCop/Gendarme needs to be applied. In the near future, I recommend bundling it with your application if you’re using it, but in the distant future, I expect it to be API stable/GAC-able.

Unfortunately, I will be taking 19 credit hours this semester, to accelerate my transition from Chemical to Computer Systems Engineering. This means I’ll have much less time to contribute, but I will continue to work on this (and my other) project.

SPECIAL THANKS

Special thanks to Google, the Mono SoC administrators, Marek, Daniel, Dick, Miguel, and everyone who commented or contributed in some way to my project! I appreciate all the support and the opportunity not to totally waste my summer.

Sincerely,
Brian Nickel

PS. Trac seems to have my IP address confused with a spammer, so I can’t report bugs on sites that don’t provide public registration. Does anyone know how I can fix this?

Advertisements

6 thoughts on “FastCGI ASP.NET Server Status Report 12

  1. 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.

    Also, what web server are you running on?

  2. Hi Brian,

    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

  3. So there’s definitely something not quite right,

    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?

  4. Okay, so I was able to get the VS.NET compiled assembly to work again via the TCP port


    /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/

  5. UPDATE: Just got back from a week long event and decided to revisit this issue a bit. It seems that using /automappaths=True instead of /applications=/:. when inside the application directory results in the same restart with every request behavior. I wonder if there might be an application directory bootstrap setting that I am missing that will aid in helping the fastcgi engine in the automap process? Out of curiosity I’ve tried,

    /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!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s