[Mono-list] mod_mono
Steve Deobald
steve@cityhost.ca
Thu, 25 Nov 2004 02:32:45 -0600
Hi Darren, Gonz, Joseph, everyone,
While we're on the topic, I figured I'd query Gonzalo on an issue the
br-mono.org guys have been having recently. I'm hosting them with the
#50049 workaround, as I am a few people, but their development is pretty
heavy. It seems that when they update assemblies on the server their
socket needs a kick (delete & re-create) before the server will
recognize a new assembly was uploaded. No one else has really noticed
this since the sockets get recreated on a pretty regular basis
anyway. :)
I've recently noticed this myself when doing some small ASP.net work for
gotmono.net. I've got all my ASP.net folks set up with a web interface
now to restart their own socket, but this isn't terribly convenient.
[Aside: I'll be releasing the code for this little web script, amongst
others, very soon. I'd like to get everything cleaned up first. Just in
case anyone else is interested.]
I'm wondering - where should I start looking to resolve this problem? Is
it mod_mono's job or XSP's to recognize an assembly has changed? If we
can come to an agreement about how to implement Darren's suggestions
this seems like something that would work right alongside. Unless I'm
way off track.
Thanks!
--
Steve Deobald
cityhost.ca
On Wed, 2004-24-11 at 22:13 -0800, Darren Martz wrote:
> > 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.
>
>
>
> _______________________________________________
> Mono-list maillist - Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list