"Killing" forever

[Robert Grosshandler]

Hi

We are experiencing several requests a day (sometimes more than several)
that will not die, even though FR is valiantly trying to kill them. Over
time, the number of these requests that are in the "killing" state grows to
be in excess of the number of simultaneous requests / threads that our
servers are licensed for. Getting an enterprise license would only delay
the problem, not fix it.

Short of restarting the CF service, anything we can do?

Thanks,

Rob

[David Stockton]

Hello Robert,

Thanks for the question.
Most likely your requests are stuck in a "native method" such as
waiting for response from the DB server or a webservice call. You can
read about this Java limitation and why FusionReactor is stuck trying
to kill them on our website - for example on this page
http://www.fusion-reactor.com/support/kb/FRS-149.cfm

As you've already twigged, you can set the simultaneous request levels
higher on your system to delay it from having a catastrophic effect
(run out of usable threads). The real fix is to find out why the
threads are getting stuck. For this you need to look at the stack
traces of the requests - I usually start with the ones that have been
running the longest as a starting point.

We offer a paid consulting service through our CFconsultant brand
( http://www.cfconsultant.com - consulting from the makers of
FusionReactor ) where we could assist you in resolving this issue if
you would like further help.

Best regards,
David Stockton
Fusion Support Team

[Robert Grosshandler]

Is it ever possible that this is a client side problem? That for some
reason the client holds the request open, can't "finish"?

Rob

Hello Robert,

--
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.

[David Stockton]

Hello Robert,

That's also possible. There's an early version of IE6 where if you hit
the back button quickly (or for some AJAX requests) it will not close
the socket properly leaving you stuck in "socketWrite0". It could also
be a denial of service attack.

The "socketWrite0" issue is already discussed in detail both on the
groups and our website technotes. We have some "hidden" features in
FusionReactor that may help mitigate this issue (if it really is the
root cause of what you're seeing). Further details are on our site:
http://www.fusion-reactor.com/support/kb/FRS-274.cfm

Best regards,
David Stockton
Fusion Support Team

On Jan 20, 3:29 pm, "Robert Grosshandler" <r...@iGive.com> wrote:
> Is it ever possible that this is a client side problem?  That for some
> reason the client holds the request open, can't "finish"?
>
> Rob
>
>
>
>
>
>
>
> -----Original Message-----
> From: fusion...@googlegroups.com [mailto:fusion...@googlegroups.com]
>
> On Behalf Of David Stockton
> Sent: Friday, January 20, 2012 9:25 AM
> To: FusionReactor
> Subject: [fusionreactor] Re: "Killing" forever
>
> Hello Robert,
>
> Thanks for the question.
> Most likely your requests are stuck in a "native method" such as waiting for
> response from the DB server or a webservice call. You can read about this
> Java limitation and why FusionReactor is stuck trying to kill them on our

> website - for example on this pagehttp://www.fusion-reactor.com/support/kb/FRS-149.cfm

>
> As you've already twigged, you can set the simultaneous request levels
> higher on your system to delay it from having a catastrophic effect (run out
> of usable threads). The real fix is to find out why the threads are getting
> stuck. For this you need to look at the stack traces of the requests - I
> usually start with the ones that have been running the longest as a starting
> point.
>

> We offer a paid consulting service through our CFconsultant brand (http://www.cfconsultant.com- consulting from the makers of FusionReactor )

[Robert Grosshandler]

Thanks, I'll dig further. If it's a denial of service attack, we're doing
it to ourselves (the client in question is something we distribute).