Emailed Stack Trace on 500 Error?

[Cameron Childress]

I've looked around in the FR admin but don't see a clear way to do this - I'd like FR to email me a stack trace anytime a 500 error occurs on a monitored server instance.  I see a way to get a stack trace when a certain CPU or memory threshold is reached, but not a way to get them when errors occur.  

Of course, I can look in the error logs on the server too, or I could use a custom error handler in the application.  But in this case I'm helping troubleshoot someone else's application and I'd really like to get a more proactive warning without having to go hunting on the server and/or changing their application code.

I see a few 500 error codes in the "Request History" in FR, but a stack trace doesn't appear to be available there either.

Am I missing it?  Is it possible?

-Cameron

--
Cameron Childress
--
p:   678.637.5072

im: cameroncf

facebook | twitter | google+

[charlie arehart]

While you await a formal answer, I’ll say that as far as I know it’s not possible, no. It’s an interesting idea, though I would note that by the time there’s a 500 error, the request has ended so any stack trace would not be what the request was “doing” (which is what FR’s stack trace always shows). Indeed, I suspect you’re thinking perhaps of how CF has sometimes shown a brief stack trace when a page got an error. That would be up to CF to do, though, not FR.

I’d think by the time FR sees that the request ended with a 500, it would be as the request was leaving CF and being sent to the browser. FR acts as a servlet filter, wrapped around CF essentially, watching requests go in and out.

It can also do the Crash Protection alerts you talked about, which are not quite about “when a certain CPU or memory threshold is reached”, but specifically when either a request exceeds a certain duration, or the number of running requests exceeds a given number, or the amount of free heap falls below a certain percent. (Not being pedantic, just clarifying for you and perhaps anyone else not yet familiar with the CP alerts.) So “memory threshold” yes, “cpu”, no. And it’s more than these.

Indeed, let’s be clear: do you really mean a 500 error happening in a CF page, or perhaps a 500 error coming back to the browser, which may be not from CF but from IIS, being unable to get the request through to CF (because perhaps all the request threads were hung). In that case, there may be no 500 errors from CF (if the requests finally finish), but users may well have gotten them.

Just suggesting that watching for 500 errors is an interesting idea, but it may not be able to show what you’d hope (the stack trace), and it may also not catch all the 500’s as you’d hope.

Any thoughts, Cam, Intergral, or anyone else?

 

/charlie

 

--
You received this message because you are subscribed to the Google Groups "FusionReactor" group.
To post to this group, send email to fusion...@googlegroups.com.
To unsubscribe from this group, send email to fusionreacto...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fusionreactor?hl=en.

[Darren Pywell]

Hi Cameron,

That's a nice idea! FusionReactor isn't able to generate and email the
stack on a certain HTTP status being set at the moment. It's a perfect
candidate for a plugin though. The idea does have some interesting
issues related to it however. A request actually becomes a 500 error
for example when a method called setStatus(500) is called on the HTTP
Response object of the request. If we would produce a stack trace at
this moment, then the stack trace would be from the setStatus(500)
method but not necessarily from the error that caused it. The reason
for this is we don't know when the real error occurs that results in
some handler (typically) setting the status to 500. I will run this by
the team and see what they come up with.

Kind Regards,
Ben
FusionReactor Support


On Feb 27, 11:06 pm, "charlie arehart" <charlie_li...@carehart.org>
wrote:

> facebook <http://www.facebook.com/cameroncf>  | twitter
> <http://twitter.com/cameronc>  | google+
> <https://profiles.google.com/u/0/117829379451708140985>

[Aaron Greenlee]

Perhaps you should consider Hoth?  http://aarongreenlee.com/share/hoth-coldfusion-errors-tracking-reporting/ 

> fusionreactor+unsubscribe@googlegroups.com.

[Cameron Childress]

Good points.  I am talking about application errors that occur inside CF - even though the details of that error may not be passed back with the response.  I suppose I think of the default CF error handler, which usually contains a trace of the error, including cause and line number.  If FR were to support capturing this, I suspect that robust exception handling and/or certain other undesirable settings may need to be turned on to make it work.

Exception information is to the exception.log file, so I think that's where FR would look to intercept it, rather than the request/response.  I'm not sure if that file/log writing activity could also be wrapped / captured as well, but that feels liek the cleanest place to grab it.  Of course I could just read that file as well.  Mainly I'm looking for situations where I may be dealing with a client issue and don't have the ability to change code - but they may let me put FR on the machine.

-Cameron

[Cameron Childress]

Thanks Ben!  It would be fantastic to get stack traces on errors.  Hopefully something comes of this...

-Cameron

im: cameroncf

facebook | twitter | google+

[Cameron Childress]

Aaron-

Hoth looks like a decent backup plan, but in this case I'm attempting to debug without any code changes.  The second I change a line of code then I know every error will get blamed on that change.  I'd rather diagnose from the outside and let my client's internal team deal with code changes.

Like I said though - I will keep it in my back pocket as a backup.

-Cameron

On Mon, Feb 27, 2012 at 8:24 PM, Aaron Greenlee <aarong...@gmail.com> wrote:

Perhaps you should consider Hoth?  http://aarongreenlee.com/share/hoth-coldfusion-errors-tracking-reporting/ 

 

--
Cameron Childress
--
p:   678.637.5072

im: cameroncf

facebook | twitter | google+