1.Kill Request 2.Request Capture 3. All variables

[Ajas Mohammed]

Hi,

I wanted to get an opinion on using Kill Request feature.

1. Kill Request. I was thinking at times we have people running huge reports causing issues in the system and I can use Kill Request feature to kill a pending request. Now I know its *unsafe* to do this but can you give your opinion if its ok to use this feature? How dangerous is this or is it ok to use to kill few requests once in a while.

2. Request Capture. I know this creates 3 files every time a page is processed. I have to say for debugging, this is an awesome resource. I wanted to point that out and also this comes with risk so it should be enabled only when required for a quick test. I love the response bin file. Its amazing. :-)

3. Is there anyway, I can look at values for all variables on a page i.e. client variables, local variables, url variables etc.

Thanks,

<Ajas Mohammed />
http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we are.
No matter what, find a way. Because thats what winners do.
You can't improve what you don't measure.
Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives.

[Darren Pywell]

1. Kill Request. Of course it's not recommened to kill things in the
VM. FusionReactor actually performs a 2 stage kill, where it tries to
ask the request to stop gracefully, and if this fails then it kills
the request forcefully. Stopping the request gracefully should have
any impact. Forcing the request to stop releases all monitors
(synchronizers / locks) that the thread currently owns which has a
slight chance of data becoming inconsistent in the application. This
could for example affect CFLOCKS that you may have, because they would
be forced to release too. Real world problems tend to come up very
rarely however from what we have seen.
http://www.fusion-reactor.com/support/kb/FRS-114.cfm
http://www.fusion-reactor.com/support/kb/FRS-25.cfm
http://www.fusion-reactor.com/support/kb/FRS-102.cfm
http://www.fusion-reactor.com/support/kb/FRS-149.cfm


2. Request Capture. This is really powerful, and with great power
comes great responsibility. You must make sure you turn request
capture off, as it can consume a lot of disk space quickly.
Take a look at Poster for Firefox. It will allow you to send one of
the .bin files back into CF to attempt the exact request again and
again!
https://addons.mozilla.org/en-US/firefox/addon/2691

3. CF Debugging Data Capture. I don't know if this is what you are
after but take a look at this DevNet article... it's very cool stuff.
http://www.fusion-reactor.com/community/developers/autodev_detailed.cfm?article=FRS-232

Cheers,
Darren

[Darren Pywell]

Oopps.. small typo above: Stopping the request gracefully SHOULDN'T
have any impact.

On Dec 11, 2:49 pm, Darren Pywell <dapyw...@googlemail.com> wrote:
> 1. Kill Request. Of course it's not recommened to kill things in the
> VM. FusionReactor actually performs a 2 stage kill, where it tries to
> ask the request to stop gracefully, and if this fails then it kills
> the request forcefully. Stopping the request gracefully should have
> any impact. Forcing the request to stop releases all monitors
> (synchronizers / locks) that the thread currently owns which has a
> slight chance of data becoming inconsistent in the application. This
> could for example affect CFLOCKS that you may have, because they would
> be forced to release too. Real world problems tend to come up very

> rarely however from what we have seen.http://www.fusion-reactor.com/support/kb/FRS-114.cfmhttp://www.fusion-reactor.com/support/kb/FRS-25.cfmhttp://www.fusion-reactor.com/support/kb/FRS-102.cfmhttp://www.fusion-reactor.com/support/kb/FRS-149.cfm

>
> 2. Request Capture. This is really powerful, and with great power
> comes great responsibility. You must make sure you turn request
> capture off, as it can consume a lot of disk space quickly.
> Take a look at Poster for Firefox. It will allow you to send one of
> the .bin files back into CF to attempt the exact request again and

> again!https://addons.mozilla.org/en-US/firefox/addon/2691

>
> 3. CF Debugging Data Capture. I don't know if this is what you are

> after but take a look at this DevNet article... it's very cool stuff.http://www.fusion-reactor.com/community/developers/autodev_detailed.c...

>
> Cheers,
> Darren
>
> On Dec 10, 6:51 pm, Ajas Mohammed <ajash...@gmail.com> wrote:
>
>
>
> > Hi,
>
> > I wanted to get an opinion on using Kill Request feature.
>
> > 1. Kill Request. I was thinking at times we have people running huge reports
> > causing issues in the system and I can use Kill Request feature to kill a
> > pending request. Now I know its *unsafe* to do this but can you give your
> > opinion if its ok to use this feature? How dangerous is this or is it ok to
> > use to kill few requests once in a while.
>
> > 2. Request Capture. I know this creates 3 files every time a page is
> > processed. I have to say for debugging, this is an awesome resource. I
> > wanted to point that out and also this comes with risk so it should be
> > enabled only when required for a quick test. I love the response bin file.
> > Its amazing. :-)
>
> > 3. Is there anyway, I can look at values for all variables on a page i.e.
> > client variables, local variables, url variables etc.
>
> > Thanks,
>
> > <Ajas Mohammed />http://ajashadi.blogspot.com
> > We cannot become what we need to be, remaining what we are.
> > No matter what, find a way. Because thats what winners do.
> > You can't improve what you don't measure.
> > Quality is never an accident; it is always the result of high intention,
> > sincere effort, intelligent direction and skillful execution; it represents

> > the wise choice of many alternatives.- Hide quoted text -
>
> - Show quoted text -

[Ajas Mohammed]

Thanks Darren,

That was very helpful information.

<Ajas Mohammed />
http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we are.
No matter what, find a way. Because thats what winners do.
You can't improve what you don't measure.
Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives.

--

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.