Am I seeing 2 Threads

[djokeefe]

I am using Fusion Debug to try and locate a difficult problem I am
having, and my question is specific to correctly interpeting what I am
seeing in the debugger.

In a MGU/Reactor/Coldspring app, I am having an issue with one of my
controller events causing data in a table to be doubled up. Using the
MG debugging, event.addTrace, dumps, etc, it was appearing that the
function was running twice. I started fusionDebug and added a
breakpoint near the top of the function, ran the code, and when
fusionDebug caught it, there are 2 separate threads kicked off. I step
my way through the first thread, everything looks good, that thread
ends, and the 2nd one is still hanging open, and the browser is
waiting for it. If I start to step through the 2nd thread, I am back
in the function I am suspecting of running twice.

Is this in fact 2 threads running simultaneously?

Thanks,

Dan

[charlie arehart]

Dan, I have only a little time to reply. Yes, it certainly is 2 threads
running simultaneously. FD really does track each request against a page
that you're debugging. But note that it's not limited to showing only YOUR
request, from some one browser. If another user kicked off a request, or
indeed if you fired off another request in another browser or another
browser window, that would show up as a second running thread.

But if you really think it's one request that triggers them both, then by
single stepping through things from the start (or some point before you know
they're not both running), you should be able to immediately see when the
2nd request thread pops up. Hope that helps.

/charlie

[djokeefe]

> But if you really think it's one request that triggers them both, then by
> single stepping through things from the start (or some point before you know
> they're not both running), you should be able to immediately see when the
> 2nd request thread pops up. Hope that helps.
>
> /charlie
>

Thanks Charlie. It is hard to see where it was being triggered since
this is a model.glue app and event=eventName is handled by an XML
file, and I do not think FD will stop at a breakpoint in an XML file.
I would have to dig into the MG code, somewhere in the event handler
and set a break point there, or maybe even go back to index.cfm and
set the breakpoint at the beginning.

I have resolved it and it was very bazaar. The issue causing the 2
threads to kick off was the following:

onclick="location.href='index.cfm?
event=Report.SetupStep3&firstID=1381&secondID=156';"

This is part of a multi step process with back and forward buttons. If
I change this to a straight href link, it only kicks off one thread
and my problem goes away.

So I am going to re-work that but would be interesting to know why the
location.href had that effect. But even if I did set a break point
somewhere earlier, I don't think it would have caught this since it is
JS kicking it off. But, FD did immediately confirm to me I had 2
threads running which was a huge help.

Thanks,

Dan

[charlie arehart]

Glad you solved the problem. Yeah, FusionDebug. :-)

As to your first paragraph, right, no, FD won't "stop at a breakpoint in an
XML file". You would have to find the CFML reading and processing such an
XML file, but I see you sorted it otherwise.

As for the root problem, your refernece to
onclick="location.href='somepage.cfm';", I think you'll find that if you
were to add a return false after that semi-colon, the problem would stop.
It's a concept often used when one wants to override a submit button to have
an onlick do something (such as submitting the page) and you don't want the
onlick to then be processed to do the form submission.

I did a quick test where I made a submit button having that onclick, and I
pointed it at a long-running page (so I could catch it running in
FusionReactor), and I made the form action go to the same page. Sure enough,
both ran when I clicked the button. And the "return false" stopped it. Hope
that's helpful.

/charlie


-----Original Message-----
From: fusio...@googlegroups.com [mailto:fusio...@googlegroups.com] On
Behalf Of djokeefe
Sent: Saturday, February 21, 2009 10:38 AM
To: FusionDebug

[Dan O'Keefe]

On Sat, Feb 21, 2009 at 10:30 AM, charlie arehart
<charli...@carehart.org> wrote:
>
> Glad you solved the problem. Yeah, FusionDebug. :-)
>
> As to your first paragraph, right, no, FD won't "stop at a breakpoint in an
> XML file". You would have to find the CFML reading and processing such an
> XML file, but I see you sorted it otherwise.

Has this changed in version 3? I see you can set up custom extensions.

Dan

[charlie arehart]

Someone from Intergral should confirm, but I would say no. FD can only debug
code that is executing CFML or Java under the covers, and the extensions
feature (http://www.fusion-reactor.com/fd/featurefocus/customextensions.cfm)
can only help you if you configure CF to have it process a particular file
extension for CFML tags/functions, as discussed for example in a blog entry
pointed to from that page:
http://www.talkingtree.com/blog/index.cfm/2006/2/17/CF-Custom-File-Extension
s.

Even if you told CF to "process" the xml extension, it (and the debugger)
would only look for lines of executable code (CFML) in the XML file. You're
asking about stepping through the reading of the file, right? The only
solution to that (I'd think) would be instead to simply step through the
execution of the CFML code that reads the XML file. Does that help?

Perhaps the Intergral folks could tweak that customextensions page to make
it more clear that this file extensions feature only allows FD to step
through executable CFML code that's found in the newly named extension.

/charlie


> -----Original Message-----
> From: fusio...@googlegroups.com

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

[Dan O'Keefe]

Thanks Charlie, makes sense the way you explain it.

Dan
--------------
Dan O'Keefe



On Tue, Dec 15, 2009 at 11:17 AM, charlie arehart