Re: [Mono-dev] mod_mono and xsp patches
Marek Habersack wrote: > On Mon, 21 Jan 2008 13:45:54 -0500, Joshua Tauberer <[EMAIL PROTECTED]> > scribbled: >> Great, in that case, I'm attaching another patch for mod_mono that >> implements rate limiting. I had found that under relatively heavy load, >> mod-mono-server would deadlock. Incoming requests would hang forever, >> with the result that all of the Apache child processes would get tied up >> as more requests came in, and so all websites on the server would stop. ... > Great stuff :) - please commit, thanks! Great, now I'm up to date with SVN. And I can let it be known that, with these changes, I've had no problems with mod_mono for many months under ~50k pageviews per day. There is still some issue on httpd start (emitting right to the console and not to the error log): File exists: Failed to create shared memory segment for backend '...' at '/tmp/mod_mono_dashboard_..._2'. It doesn't seem to actually cause any problems, but it is very strange. The named file does not exist when Apache starts, and trying to unlink it right before the call that's causing that error doesn't do any good. It nevertheless complains about the file existing. -- - Josh Tauberer http://razor.occams.info "Yields falsehood when preceded by its quotation! Yields falsehood when preceded by its quotation!" Achilles to Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Web.Compilation Error On XSP2
Hi, I write a web framework(njoy) for mono. I try to running with PostgreSQL + Subsonic 1.06. I use mono-1.2.6 on winxp. But I get below error! Is it this bug? Or What is a solution? Note: Sorry my bad english!. *Argument cannot be null. Parameter name: virtualPath* *Description: *Error processing request. *Error Message: *HTTP 500. System.ArgumentNullException: Argument cannot be null. Parameter name: virtualPath *Stack Trace: * System.ArgumentNullException: Argument cannot be null. Parameter name: virtualPath at System.Web.VirtualPathUtility.IsAbsolute (System.String virtualPath) [0x0] at System.Web.VirtualPathUtility.IsRooted (System.String virtualPath) [0x0] at System.Web.VirtualPathUtility.Normalize (System.String path) [0x0] at System.Web.VirtualPathUtility.Combine (System.String basePath, System.String relativePath) [0x0] at System.Web.Hosting.DefaultVirtualDirectory.AddFiles (System.Collections.ArrayList list, System.String dir) [0x0] at System.Web.Hosting.DefaultVirtualDirectory.get_Files () [0x0] at SubSonic.BuildProvider.CheckExtensionTypes (System.Web.Hosting.VirtualDirectory path) [0x0] at SubSonic.BuildProvider.GenerateCode (System.Web.Compilation.AssemblyBuilder assemblyBuilder) [0x0] at System.Web.Compilation.AppCodeAssembly.Build (System.String[] binAssemblies) [0x0] at System.Web.Compilation.AppCodeCompiler.Compile () [0x0] at System.Web.HttpApplicationFactory.InitType (System.Web.HttpContext context) [0x0] -- Hasan Ozgan(a.k.a meddah) Software Architect (http://www.meddah.org) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mod_mono and xsp patches
On Mon, 21 Jan 2008 13:45:54 -0500, Joshua Tauberer <[EMAIL PROTECTED]> scribbled: > Marek Habersack wrote: > > They're OK to go in, thanks! > > Great, in that case, I'm attaching another patch for mod_mono that > implements rate limiting. I had found that under relatively heavy load, > mod-mono-server would deadlock. Incoming requests would hang forever, > with the result that all of the Apache child processes would get tied up > as more requests came in, and so all websites on the server would stop. > > There are only so many worker threads in the XSP thread pool, and at a > certain point they're going to get used up. I forget how many threads > there are by default, maybe 128, but at a few workers per request, that > number gets used up quickly. Obviously the right thing to do would be to > make sure mod-mono-server doesn't hang when it runs out of worker > threads (if this was even the problem), but barring a fix there, this > did the job. It would be a good thing to make sure that the thread pool exhaustion was causing the problem, but even without doing it - I think such rate limiting is a good thing to have. > In my case, I was having problems when the number of concurrent requests > went above 20 or 25. (I forget the details. I've been using this patch > for around 3-4 months... modulo changes I made today.) > > The patch by default limits the number of concurrent requests passed to > mod-mono-server to 20. After that, it holds onto (by default) up to 20 > more, checking periodically until the initial 20 decreases or a timeout > (hard-coded at 10 seconds). The two 20's are configurable with > MonoMaxActiveRequests and MonoMaxWaitingRequests. > > This will only work on Apache2 since it relies on the shared memory > dashboards. Great stuff :) - please commit, thanks! best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mod_mono and xsp patches
Marek Habersack wrote:
They're OK to go in, thanks!
Great, in that case, I'm attaching another patch for mod_mono that
implements rate limiting. I had found that under relatively heavy load,
mod-mono-server would deadlock. Incoming requests would hang forever,
with the result that all of the Apache child processes would get tied up
as more requests came in, and so all websites on the server would stop.
There are only so many worker threads in the XSP thread pool, and at a
certain point they're going to get used up. I forget how many threads
there are by default, maybe 128, but at a few workers per request, that
number gets used up quickly. Obviously the right thing to do would be to
make sure mod-mono-server doesn't hang when it runs out of worker
threads (if this was even the problem), but barring a fix there, this
did the job.
In my case, I was having problems when the number of concurrent requests
went above 20 or 25. (I forget the details. I've been using this patch
for around 3-4 months... modulo changes I made today.)
The patch by default limits the number of concurrent requests passed to
mod-mono-server to 20. After that, it holds onto (by default) up to 20
more, checking periodically until the initial 20 decreases or a timeout
(hard-coded at 10 seconds). The two 20's are configurable with
MonoMaxActiveRequests and MonoMaxWaitingRequests.
This will only work on Apache2 since it relies on the shared memory
dashboards.
--
- Josh Tauberer
http://razor.occams.info
"Yields falsehood when preceded by its quotation! Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)
Index: ChangeLog
===
--- ChangeLog (revision 93419)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2008-01-21 Joshua Tauberer <[EMAIL PROTECTED]>
+
+ * src/mod_mono.c: Implemented configurable rate limiting
+ with MonoMaxActiveRequests and MonoMaxWaitingRequests.
+
2008-01-20 Joshua Tauberer <[EMAIL PROTECTED]>
* src/mod_mono.c:
Index: src/mod_mono.c
===
--- src/mod_mono.c (revision 93419)
+++ src/mod_mono.c (working copy)
@@ -63,6 +63,8 @@
uint32_t handled_requests;
time_t start_time;
char restart_issued;
+ int active_requests;
+ int waiting_requests;
} dashboard_data;
typedef struct xsp_data {
@@ -90,7 +92,9 @@
char is_virtual; /* is the server virtual? */
char *start_attempts;
char *start_wait_time;
-
+ char *max_active_requests;
+ char *max_waiting_requests;
+
/* auto-restart stuff */
auto_restart_mode restart_mode;
uint32_t restart_requests;
@@ -446,6 +450,8 @@
xsp->dashboard->start_time = time (NULL);
xsp->dashboard->handled_requests = 0;
xsp->dashboard->restart_issued = 0;
+xsp->dashboard->active_requests = 0;
+xsp->dashboard->waiting_requests = 0;
}
}
}
@@ -510,6 +516,8 @@
server->start_attempts = "3";
server->start_wait_time = "2";
server->no_flush = 1;
+ server->max_active_requests = "20";
+ server->max_waiting_requests = "20";
#ifndef APACHE13
apr_snprintf (num, sizeof (num), "%u", (unsigned)config->nservers + 1);
@@ -1895,6 +1903,118 @@
}
static int
+increment_active_requests (xsp_data *conf)
+{
+ apr_status_t rv;
+
+ int max_active_requests = atoi(conf->max_active_requests);
+ int max_waiting_requests = atoi(conf->max_waiting_requests);
+
+ /* Limit the number of concurrent requests. If no
+ * limiting is in effect (or can't be done because
+ * there is no dashboard), return the OK status.
+ * Same test as in the decrement function. */
+ if (max_active_requests == 0 || !conf->dashboard_mutex || !conf->dashboard)
+ return 1;
+
+ rv = apr_global_mutex_lock (conf->dashboard_mutex);
+ /* Drop the request on failure to lock the dashboard because
+ * we don't want to decrement the counter later since we couldn't
+ * increment it here. */
+ if (rv != APR_SUCCESS)
+ return 0;
+
+ // From here on, rv holds onto whether we still have
+ // the lock acquired, just in case some error ocurrs
+ // acquiring it during the loop.
+ if (conf->dashboard->active_requests >= max_active_requests) {
+ /* We need to wait until the active requests
+ * go below the maximum. */
+
+ /* However, we won't keep more than max_waiting_req requests
+ * waiting, which means the max number of active Apache
+ * connections associated with this mod-mono-server
+ * is max_active_req+max_waiting_req.
+ */
+ if (conf->dashboard->waiting_requests >= max_waiting_requests) {
+ apr_global_mutex_unlock (conf->dashboard_mutex);
+ ap_log_error (APLOG_MARK, APLOG_ERR, STATUS_AND_SERVER,
+ "Maximum number of concurrent mod_mono requests to %s reached (%d active, %d waiting). Request dropped.",
+ conf->dashboard_lock_file, max_active_requests, max_waiting_requests);
+ return 0;
+ }
+
+ ap_log_error (APLOG_MARK, APLOG_INFO,
[Mono-dev] Failed to create shadow copy (CopyFile).
I have two real world projects that thow this exception with Mono. How do I find what exactly the problem is. This exception is vague! An if only there was a debugger!? /Failed to create shadow copy (CopyFile)./ *Description: *Error processing request. *Error Message: *HTTP 500. System.ExecutionEngineException: Failed to create shadow copy (CopyFile). *Stack Trace: * System.ExecutionEngineException: Failed to create shadow copy (CopyFile). at (wrapper managed-to-native) System.Reflection.Assembly:load_with_partial_name (string,System.Security.Policy.Evidence) at System.Reflection.Assembly.LoadWithPartialName (System.String partialName, System.Security.Policy.Evidence securityEvidence, Boolean oldBehavior) [0x0] at System.Reflection.Assembly.LoadWithPartialName (System.String partialName, System.Security.Policy.Evidence securityEvidence) [0x0] at System.Reflection.Assembly.LoadWithPartialName (System.String partialName) [0x0] at System.Web.Compilation.AssemblyPathResolver.GetAssemblyPath (System.String assemblyName) [0x0] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mod_mono and xsp patches
On Sun, 20 Jan 2008 08:29:01 -0500, Joshua Tauberer <[EMAIL PROTECTED]> scribbled: > Hi, Hey Joshua, > > I have two sets of patches: for mod_mono and xsp. > > The mod_mono patch corrects a few minor things, like proper destruction > of the new shm's and checking everything is initialized. > > The xsp patch corrects a check that a request ID is valid by putting it > within a lock, because requests could be finished after the check and > before the lock is entered. > > If these are OK, I have another mod_mono patch to follow. They're OK to go in, thanks! best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.2.6 / gmcs: compilation fails on unsafe array constructor.
Hi Stephen,
> The following code fails to compile:
>
> class Bug
> {
> unsafe int*[] data = new int*[16];
> }
>
Could you please fill a bug report for this issue.
Thanks
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
