[Mono-bugs] [Bug 73619][Cri] Changed - mod_mono does not recover when the system is busy or mod-mono-server fails to quit

[bugzilla-daemon@bugzilla.ximian.com]

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 gonzalo@ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=73619

--- 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 @@
 Bug#: 73619
 Product: Mono: Tools
 Version: 1.1
-OS: 
+OS: unknown
 OS Details: 
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Critical
 Component: mod_mono
 AssignedTo: gonzalo@ximian.com                            
 ReportedBy: rlyon@novell.com               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
@@ -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
 with Mono.
+
+------- Additional Comments From gonzalo@ximian.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
+the nullref.
+
+> 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
+running.
+
+> 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
+startup.
+
+
+ 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
+mod_mono?
+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.