[Mono-list] mod_mono

[Darren Martz]

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

Having a balance between an easy to use configuration and a super-flexible
configuration is certainly ideal. 

What you describe certainly allows a fair amount of control over the server
process. Bringing the more advanced features such as multiple processes to
the "easy to use" side could only advance mod_mono's reputation.

Right now the admin is required to manually create a directory per
application and add supporting MonoUnixSocket/MonoWapiDir entries to the
config file. The config entries are basic to write, but the manual creation
of  unique directories requires manual intervention. If mod_mono were to
auto-create the unique sub-folders on demand, it would be far simpler to
configure multiple applications. Take the following for a lengthy example:

<Location /TestA>
	MonoGroup MyAppOne
	MonoApplication /TestA:/var/www/TestA/
</Location>

<Location /TestB>
	MonoGroup MyAppOne
	MonoApplication /TestB:/var/www/TestB/
</Location>

<Location /TestC>
	MonoGroup MyAppTwo
	MonoApplication /TestC:/var/www/TestC/
</Location>

<Location /TestD>
	MonoApplication /TestD:/var/www/TestD/
</Location>

<Location> /TestE>
	MonoUseXSP False
	MonoUnixSocket /tmp/mycustom/mod_mono_server
	MonoWapiDir /tmp/mycustom/
	MonoApplication /TestE:/var/www/TestE/
</Location>

Given the above five mono applications, on Linux the following directories
would be created:

# apps TestA and TestB would use the following
/tmp/mod_mono/MyAppOne/.wapi
/tmp/mod_mono/MyAppOne/mod_mono_server

# app TestC would use the following
/tmp/mod_mono/MyAppTwo/.wapi
/tmp/mod_mono/MyAppTwo/mod_mono_server

# app TestD would use the following
/tmp/mod_mono/Default/.wapi
/tmp/mod_mono/Default/mod_mono_server

The user would be responsible to create the /tmp/mod_mono/ directory, but
the remaining sub-directories would be generated by the module. Powerful and
easy to use. The TestE example would be completely controlled externally as
you described.

On Windows that would instead create the following named pipes (same config
file):

//./mod_mono/MyAppOne
//./mod_mono/MyAppTwo
//./mod_mono/Default

The TestE example on Windows would not work cause the MonoUnixSocket would
not likely be ported.
 
> 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.

Due to the large performance differences between named-pipes and sockets in
Windows, I strongly suggest investigating a different approach. In my
experience, when the client and the server reside on the same box, pipes
have a huge performance gain over sockets any day. Take SQL Server for
instance, do a test between pipes and sockets and witness the results for
yourself.
 
> 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.

What goes wrong with the MPM with processes? I still have a lot to learn on
the Linux side of coding. The code appears to attempt a connection to the
mod-mono-server each request. With multiple worker threads it would seem
that each thread tries to connect and goes from there. I could certainly see
a conflict if the server was not running or was overloaded.

It seems like some form of process-pool logic could be of value here.
 
 
> Depending on the setup, there might be other instances of 
> mono running and using the same directory, so this is not an option.

I can see this being a problem for default directory setups. However, for
the MonoGroup "unique" sub-directories described in the above example, this
would not be a problem. 

The nice part is it's the best of both worlds - fully automatic and fully
controllable.