Re: detecting & retrying after a 500 error result

I know that feeling only too well.

could you redirect all of your requests to a separate rewrite map or  
set of conditions?  On my external interfaces I always proxy/redirect  
to localhost and then set up a rule system there to handle errors  
(where possible).


I am using fastcgi (well fcgx extensions) for a credit card  
processing system -- what I am doing is catching things at the  
pass... right before I send back to the point-of-sale.... if the  
document that I am going to output (ostringstream'd) is not a valid  
document then I return back a 204 (empty doc).

Then for catching buggy mistakes (not that I ever make them :) :)  --  
I have a try...catch at the very outer loop - and I have sigactions  
on all the signals that I can possibly get.


On Feb 28, 2011, at 2:14 PM, Michael Richards wrote:

> I've been looking at that possibility but the server appears to do  
> a redirect to display any custom error_info pages and as a result  
> the original POST or GET data seems to run and hide from me.  
> Ideally I'd love to have it completely hide the fact there was an  
> internal server error from the end user. It's been years since I  
> fooled with the mod_fastcgi code so I don't begin to understand it  
> anymore.
>
> -Michael
>
> On Mon, Feb 28, 2011 at 3:08 PM, Tom Bowden  
> <[email protected]> wrote:
> could you do something funky like associate a custom error handler  
> on the 500 code - that restarted the server/server-process and then  
> returned back the response to client?
>
>
>
> On Feb 28, 2011, at 12:55 PM, Michael Richards wrote:
>
> I run a large webmail system and occasionally a process dies and  
> returns internal server errors. While this occurs only about  
> 1/70,000 requests, it does cause problems as one of the processes  
> in the pool will always return an internal server error. Is there a  
> way that the process manager can be modified to automatically  
> restart any process that returns an internal server error? How  
> about retrying the request as well so the internal server error is  
> never seen by the user? Obviously I would like to find all the bugs  
> in the software, but a million lines of code and a very slim chance  
> of a problem means it's difficult to justify spending a lot of time  
> on.
>
> -Michael
> _______________________________________________
> FastCGI-developers mailing list
> FastCGI-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
> http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers
>
>
>
>
> -- 
> Michael Richards
> PSI Tuning Inc
> 649 Auguste-Mondoux Unit 1B
> Gatineau, Quebec,
> Canada
> J9J 3K2
> Phone: 819-778-7047
> Cell:
> Email: Personal  [email protected]
> Email: Business [email protected]

_______________________________________________
FastCGI-developers mailing list
FastCGI-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers