[Mono-list] mod_mono

[Gonzalo Paniagua Javier]

On Wed, 2004-11-24 at 15:39 -0800, Darren Martz wrote:
> Gonzalo,
>  
> I have been looking over the mod_mono source and have a few thoughts. Before
> you read on, please don't take offence to anything I write that may
> accidentally offend... I am just trying to help.

Heh. Let's see ;-).

> 
> It seems the way to create a separate mod-mono-server process per
> "MonoApplication" is to change the MonoUnixSocket value to a unique address,
> or use unique MonoListenAddress/MonoListenPort values. On Linux a unique
> .wapi directory is also necessary using the MonoWapiDir statement.

There's other alternative that works for other apache models than
prefork: running mod-mono-server by yourself. This way you only have to
tell the module not to fork (MonoRunXSP false) and you can set its own
user, .wapi dir, etc. You'll want to start/stop this 'daemon' when
apache starts/stops (the --terminate option was added recently to
mod-mono-server so that you can shutdown gracefully a running
mod-mono-server).

Other advantages of this way of managing applications is that you don't
need to restart mod-mono-server if you've changed unrelated stuff in the
apache configuration.

> Pooling MonoApplications into one or more mod-mono-server processes is not
> an obvious outcome of MonoUnixSocket and MonoWapiDir. The MonoWapiDir only
> makes sense to people working on XSP and mono, and the MonoUnixSocket is not
> likely to be relevant in a Windows environment - assuming a port to Windows.

Angel Marin is working on it and is using the TCP socket, not the unix
socket which, btw, is available from certain version of the windows API,
but not likely to be used in Angel's port.

> 
> What if we combined all of that into something a bit more direct, something
> like the following entries:
> 
> 	MonoGroup $GroupName
> 	MonoTemp /tmp/mod_mono/
> 
> [the notation of $GroupName indicates to replace with your own groupname
> such as "nGallery"]
> 
> The MonoTemp sets a generic temp directory where both the .wapi directory
> and the mod-mono-server socket exist. That is the equivalent of writing the
> following with today's syntax:
> 
> 	MonoUnixSocket /tmp/$GroupName/mod-mono-server
> 	MonoWapiDir /tmp/$GroupName/.wapi
> 
> So why consider changing the syntax? The entries are completely unique to
> Linux requiring a new set of commands for a Win32 port. The outcome of using
> these commands is to control unique processes of mod-mono-server regardless
> of the host platform. This is our way of controlling groups of
> MonoApplications/mod-mono-server processes, what I'll refer to as
> "application pools". A common syntax that supports application pools across
> multiple platforms seems logical/ideal.

I still like more the setup I said above. Have you tried running apache
using the MPM worker thread model? You'll see it failing miserably to
spawn mod-mono-server because of how apache manages processes.

> 
> 
> Due to bug #50049 we apparently need to create a unique mod-mono-server
> process per MonoApplication.

Right :(

> 
> On Linux this means the mod-mono-server file and the .wapi directory always
> reside in the same [sub]directory. Maybe that is a problem for a few, but I

You can use MonoWapiDir on a per-location basis.

> understand others are already doing it manually. Others have created scripts
> to cleanup the .wapi and mod-mono-server reminisce when apache is
> reloaded/stopped - something mod_mono could do in the terminate_xsp
> function.

Depending on the setup, there might be other instances of mono running
and using the same directory, so this is not an option.

> 
> Porting mod_mono to Windows *could* mean that MonoTemp is ignored (or used
> for something else) and MonoGroup translates into a named pipe called
> "//./pipe/mod-mono/$GroupName", or shared-memory name, or something like
> that. That means the syntax/documentation could remain constant between
> Unix/Linux/Mac/Windows but allow for an OS optimized implementation.

You can modify the temporary directory in web.config. In fact I just
replied to someone else wrt that. The answer is:
<configuration>
        <system.web>
                <compilation tempDirectory="/blah/blah" />
        </system.web>
</configuration>

But, really, you normally don't care about where the system places the
temp files it creates.

> 
> My interest in this? Coming from the windows C/C++ world I'd like to see an
> alternative on Windows for asp.net and am considering writing the port
> myself if nobody else is up to the challenge. That would help many
> businesses wanting to move away from IIS but towards Asp.Net that are not
> ready to commit to a Linux platform.

As I said, Angel Marin is porting mod_mono to windows.

After reading your email I found no offense at all, but someone really
interested and motivated in using our work ;-).

Lemme know if there's something wrong with the alternative approach that
I proposed (that requires no changes in the code, but a couple of
scripts).

Thanks for your time.

-Gonzalo