[Mono-bugs] [Bug 648193] xsp2 stops responding if application files are touched more than once (while busy)

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=648193

https://bugzilla.novell.com/show_bug.cgi?id=648193#c3


Marek Habersack <mhabersack at novell.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|Major                       |Normal

--- Comment #3 from Marek Habersack <mhabersack at novell.com> 2010-10-21 13:02:44 CEST ---
Hey Tom,

  So,there are a few things going on here, and some more workarounds for the
situation. First a word of explanation:

  XSP/mod-mono-server* work in an optimized mode when only one application is
configured - the optimization consists in creating just one AppDomain to be
shared by both the server instance (the main xsp/mod-mono-server workhorse) and
the application. This has the advantage that requests are served faster (no
need to remote between two AppDomains) but it also has a disadvantage that when
something bad/unexpected happens in the application, it may take the server
down with it. It also takes the server down if the AppDomain is shutdown
because of some regular event like bin/* or /Web.config modification. In both
cases XSP/mod-mono-server attempt to restart the AppDomain and rebind to the
listening socket but, from time to time, it may fail. The failure is due to
some race in AppDomain shutdown or socket teardown/shutdown sequence and
manifests itself in the socket not being closed properly at times. We are aware
of the issue and are investigating it. Sometimes it may happen that the socket
not destroyed correctly is the one XSP/mod-mono-server are listening on and it
is not possible to rebind to that socket, thus effectively rendering the server
inoperable. It is also the cause of the hung connections from client to server
- only in that case it's only that particular client session which times out
(after 10 minutes on Linux by default) and it does not affect other clients. 
   The race in socket shutdown sequence may also lead to sockets being closed
but with some data still in the output buffer (in the native socket, managed by
the OS, not in Mono) which will keep the socket in CLOSE_WAIT state until it
times out or is destroyed in some other manner.
   The ThreadAbortException is also a manifestation of a (yet) unknown race -
we are also aware of it and looking for solution. System.Web itself uses
Thread.Abort (which throws the exception) only if user's code calls
HttpRequest.{Redirect,End} methods or if a request timeout happens, so it's a
pretty controlled use and it's not the issue here.

   With the above in mind, backup software which touches files all around the
ASP.NET app is not really a good idea. If an .as?x file is touched, ASP.NET
runtime will trigger a recompile of that file only, but if anything inside
bin/* or /Web.config is touched (probably in sequence) then it is possible a
few AppDomain shutdowns and full recompilation of the entire app will happen -
it is an unnecessary waste of time and resources.

   You can use the following workarounds until we find the races and fix the
issues I described above:

 - if you can't change the backup software or modify it so that it doesn't
touch the files, you can disable file watching by exporting the
MONO_MANAGED_WATCHER=disabled variable in the application's environment
 - to remedy the server shutdown issue and the resulting inresponsiveness,
configure _two_ applications for that server (the other one can be a dummy one
or can point to the same application, just with a different virtual directory),
e.g.:

   - XSP: pass --applications "/myrealapp:/path/to/app,/dummy:/path/to/app"
   - mod_mono: add MonoApplications server_alias_here
"/myrealapp:/path/to/app,/dummy:/path/to/app"

  The above will have the server work in the multiple AppDomains mode and only
the application AppDomain will be affected by shutdown/TAEX/etc

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.