095 RC2 Too many forward attempts issue

@Paul : Thanks for clarifying the technicalities, I have not followed this thread very closely and I am not judging on the content of the request, but the process.

Yet, since you mention DB issues : let’s remind that Piwaille is hosted on a "low grade" shared hosting as part of a promotionnal operation which took place a few months ago for the french host OVH (every .info domain was free of charge, along with the 1000gp - a 1Gb disk space - hosting, for life).

I had friends taking up that offer, and took one for my girlfriend : better than usual free hosting I thought... the thing is they have re-used old servers with old drives for the purpose, and the performances are really awful. I had to move my girlfriend blog just a month after installing it, performance degradation was really crazy for such traffic, something around 300 page views per day (the blog software I used was DotClear, which is known to be light on resources and well optimized). I had repeated problems connecting to phpMyAdmin (unable to login) and then to download the dump before moving the blog to another server. Bad experience. Never checked before tonight where Piwaille was hosted, and never made the connection otherwise I would have mentionned it.

The environment is not cutting edge either, if I recollect correctly PHP 4.4.4 and MySQL 3.23... I don’t know if it’s related and I did not re-read the thread but there might be something here...

@ZAP : Thanks for the kind words. I won’t loose sleep over this, nor will it raise my blood pressure one bit...

You know, I actually just thought of a possible patch for this issue...

Back when I was using Etomite, I hacked the error-forwarding code to redirect to an actual HTML file instead of a parsed error page (I can’t remember why I did that now; something about its error-handling not working properly within subdirectories). Anyway if I understand this correctly the function is trying to forward to the error or unauthorized page, it’s getting no response from the database server when it tries, and so it’s again trying to redirect to the error page, etc. What if the error page were an actual HTML file that would be (relatively) immune to server lag or malfunction?

Perhaps the config option for the error document could be either a document id or an actual URL, or perhaps just adding an HTML file with the correct alias as its name would be fine as long as you’re using FURLs...

404 doesn’t redirect, so it wouldn’t pick up the .html file from the root.

I do like having a dynamic 404 page though, so really what I’d like to see is a "db not available" setting which would load a previously generated page. The best thing would be for that to be a page ID just like the 404 and unauthorised pages, but behind the scenes MODx would save the file (probably in /export, given that the installer requires you to have that folder writeable).

Having it this way means that the design of it can be handled better.

Quote from: PaulGregory at Dec 14, 2006, 08:30 PM

404 doesn’t redirect, so it wouldn’t pick up the .html file from the root.

I do like having a dynamic 404 page though, so really what I’d like to see is a "db not available" setting which would load a previously generated page. The best thing would be for that to be a page ID just like the 404 and unauthorised pages, but behind the scenes MODx would save the file (probably in /export, given that the installer requires you to have that folder writeable).

Having it this way means that the design of it can be handled better.

I agree that it’s nice to have a dynamic 404 page (show people possible options for what they seem to be looking for, etc.). I was thinking of a sort of "major error" or "crisis" page that could be forwarded to when the other doesn’t respond. Something very similar to your "database unavailable" page.

If I understand your reply, you’re saying that since MODx doesn’t receive a response from the database it won’t know where to forward to the HTML file either. Is that right? What if it had a hard-coded default URL (or one that was written to the config file)?

It seems as if some version of this idea (a "database unavailable" HTML page) would be a good addition for the long-term, and perhaps there’s some variation of the idea that could be implemented as a hack for temporary use with unreliable database servers.

Also: It seems that some database activity is definitely ocurring, since it’s filling up the error log. So that may mean that I’m not understanding the nature of this situation properly, since I’m assuming that the root of the problem is a nonresponsive database. Another patch (that seems logical to me) would be to run an extra query before adding to the event log to truncate it if there are more than say 1,000 entries in there.

But then again, if all this fiddling is just a waste of time and effort because future versions of MODx won’t share this code, then there’s no reason to do that.

Hey guys, I really think this has everything to do with the MODx custom php error handler code that tries to insert into the database log to record a php error. I have the feeling somehow the database is still making a connection but unable to fulfill the request and the error log insert just makes it worse.

Regardless of that part of the issue, I do think we can allow static redirects for temporarily unavailable 503 responses, which is the proper one for situations when server resources are overloaded, according to the specs. And other special responses (404, etc.) could be handled the same way. I am just fairly certain this is all ties back to error handling problems, and I’d rather address it in the new branch (if it is still an issue in any way), and not worry about it retro-actively in 0.9.5.

Makes sense to me. No reason to put rocks in your pockets when you’re trying to get 0.9.7 out soon. What do you think about limiting the total size of the error log table just in case something simliar ever happens?

Quote from: ZAP at Dec 15, 2006, 10:50 AM

Makes sense to me. No reason to put rocks in your pockets when you’re trying to get 0.9.7 out soon. What do you think about limiting the total size of the error log table just in case something simliar ever happens?

Logging errors to the database is the problem...how can you log a database error if logging an error to the database is the problem? IMO, 0.9.7 errors should be logged to the standard PHP error log (or a custom modx error log) by default.

That would allow it to log errors when the database is non-responsive, so that makes sense. I would advocate for a separate MODx error log myself, since the more independent it is the less likely it is to break or be inaccessible on some hosts. It still seems like a good idea to limit its size, imho, since a gigabyte of errors is a problem no matter where it’s stored.

Who knows how can be event logging disabled?
Maybe there is a way to cut some code from MODx sources. Please help.