charlie arehart
unread,Dec 15, 2009, 12:54:53 PM12/15/09Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to fusion...@googlegroups.com
I just noticed something that tripped up some expected crash protection
notification for someone I'm working with. I wanted to share it with others
here.
You may know that the FR Crash Protection offers 3 choices, detecting when a
request takes too long, memory is too low, or too many requests are running.
What I'd not noticed until today is that the third (requests) option
triggers not when the number provided is reached but when it is *exceeded*.
It's in the text on the screen, but I'd somehow not caught the distinction:
If a new request occurs and the number of running requests is above
this amount then the selected survival strategy will be triggered. Leave
blank to disable feature.
So if you have CF's max simultaneous requests set to 25, and you set this CP
setting to 25, you won't get notified if it hits 25. You need to instead set
the CP setting to 24, it would seem, to get the notified when it hits 25. (I
don't use the abort or queue mechanisms, but it would apply to those as
well.)
I experienced this today with this customer where the resource log showed 25
requests running for a period of several minutes (things were hung) before
we restarted CF, but there were no CP notifications (email or in the CP
log). (It turned out to be that the database stopped responding to the
requests, as the resource log's JDBC columns also showed no activity from
that point forward.)
Hope that observation about the CP setting for requests may help someone.
/charlie
PS I'll add that for CF 8 and 9 Enterprise, one can now set up different
thread max's in the CF Admin for different kinds of requests: web service
requests, flash remoting requests, and CFCs called from a URL. It's
important to note then that technically it's the sum of all these kinds of
threads which could appear as being monitored by FusionReactor. What's this
got to do with this discussion? Well, if you want to avoid getting CP
notifications before the true "max" of request threads is really reached,
you'll want to consider raising the CP notification setting. (In the case of
this server I was working with today, it's running CF Standard so just the
one max thread setting applies.)