[Mono-bugs] [Bug 73619][Cri] Changed - mod_mono does not recover when the system is busy or mod-mono-server fails to quit
Fri, 11 Mar 2005 20:01:52 -0500 (EST)
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by firstname.lastname@example.org.
--- shadow/73619 2005-03-11 19:23:48.000000000 -0500
+++ shadow/73619.tmp.8937 2005-03-11 20:01:52.000000000 -0500
@@ -1,14 +1,14 @@
Product: Mono: Tools
@@ -49,6 +49,70 @@
I am not sure who is throwing "Unhandled Exception" or why mod-mono-server
does not continue exit after it is thrown. The main runner thread (the
only non-background thread) appears to have been aborted successfully.
I know this is complex, but we are excited to be at this performance point
+------- Additional Comments From email@example.com 2005-03-11 20:01 -------
+>we have a busy server (with 200 clients) the first roll of Apache
+>(killall-HUP httpd2-worker) usually works, but the second usually
+> fails. on the second roll mod-mono-server throws:
+>Unhandled Exception: System.NullReferenceException: Object reference
+>not set to an instance of an object
+>which we see in the error_log file. I have been unable to determine
+>who is throwing this exception, but at this point mod-mono-server
+>fails to exit.
+I'll try to reproduce this condition by running mod-mono-server under
+gdb (slow) and pausing when we're told to shutdown. Let's see if i get
+> because of the hash lock file, it will not be started again.
+I can remove this lock file and the socket file immediately after
+receiving the shutdown request, before finalizing the applications
+> for robustness, I think we should start by tightenting the starting
+> of mod-mono-server using a lock file or mutex in mod_mono and remove
+> the hash lock in the mod-mono-server.
+The problem of locking in mod_mono is that mod-mono-server can be run
+from outside mod_mono. Having the lock in mod-mono-server prevents
+user errors if attempting to run the same thing twice (and if we
+remove the lock immediately we'll have better chances here).
+On the other hand, not locking in mod_mono causes forking overhead at
+ I think we need to support starting a new mod-mono-server comming up
+even if the old mod-mono-server has become defunct (or possible force
+a kill before starting again).
+>Q: how do you see the WebTracing in mod-mono-server, when running
+You have to compile with /d:WEBTRACE. The output goes to Console.Out,
+so you have to put that dup2() line in mod_mono when forking.
+ where does the output from mod-mono-server behind mod_mono go?
+stdout goes to apache stdout, which i think it's ignored. stderr goes
+to the error log.
+> I am not sure who is throwing "Unhandled Exception" or why
+> mod-mono-server does not continue exit after it is thrown. The main
+> runner thread (the only non-background thread) appears to have been
+> aborted successfully.
+I don't know if i'll be able to reproduce this inside or outside gdb,
+but i'll try.
+One question for you: is this using SVN mono/mcs/xsp/mod_mono?
+> I know this is complex, but we are excited to be at this performance
+> point with Mono.
+I'm glad to hear this and part of the "blame" is on you guys.