[FDS-128] Using FusionDebug to debug Flash Remoting and Gateway Messaging Requests

Description

Debugging Flash Remoting and Gateway Messaging

Non-Intrusive debugging has been introduced in FusionDebug 3.5, which allows breakpoints to only fire when requests are coming from a specified IP address. This makes it possible for a developer to debug and set breakpoints against a central server, leaving the system untouched and unaffected for everyone else.

This article will demonstrate that the breakpoint IP filter can be used to debug Flash Remoting and Gateway Messages. In order to demonstrate that FusionDebug’s non-Intrusive debugging functionality is effective across a wide range of message types, below is a short example of testing the filter functionality in regards to Flash Remoting messages and Gateway messaging. I have based these tests on the test classes found at http://www.cftips.net and http://www.fusioncube.net .

Flash Remoting

I created a Flex project with an mxml file containing a script that has two functions; a function that simply populates a data grid with the results returned by a remote CFC and a second function that accepts a fault event and displays an error message in case of problems. I also need a remote object call specifying a destination named ColdFusion (which is configured with the appropriate channel for the passing of messages) and specified the location of the CFC you would like to access as well as creating a data grid to store the retreived results.

Remoting.mxml
<mx:Script>
      <![CDATA[
            import mx.controls.Alert;
            import mx.rpc.events.FaultEvent;
            import mx.rpc.Fault;
            import mx.rpc.events.ResultEvent;
            
            private function result(evt:ResultEvent):void {
            	mygrid.dataProvider = evt.result;
           }

            private function fault(evt:FaultEvent):void {
                  Alert.show(evt.fault.message);                 
            }
      ]]>
</mx:Script>

<mx:RemoteObject id="mycfc" destination="ColdFusion" showBusyCursor="true" source="flashRemote" result="result(event)" fault="fault(event)">
</mx:RemoteObject>     
      <mx:Button label="Button" click="mycfc.GetData()"/>
      <mx:DataGrid id="mygrid" width="487" height="169"/>
</mx:Application>

Below are some changes that I found needed to be made to CF8 and CF9 Application servers’ configuration before the Flash Remoting test class would function correctly;
Within flex-messaging-gateway.cfg. If your Flex server is installed as part of your CF app server, comment out localhost ‘#host=localhost’. Specify ‘localhost’ if Flex is on this machine but not installed as part of ColdFusion.

For the Remoting-config.xml add the following code within the “ColdFusion” destination properties . You are setting use-mappings to true and setting the method-access-level to remote. use-mappings is a Boolean value specifying whether the source attribute can be relative to a ColdFusion mapping. Changing the method access level to remote basically specifies the access attribute values the destination CFC must have for ColdFusion to respond to the request. The code within the property-case tags simply state to make query column names, and structure keys lowercase when converting to ActionScript.

Remoting-config.xml
<destination id="ColdFusion">
   <channels>
      <channel ref="my-cfamf"/>
   </channels>
   <properties>
      <source>*</source>
   <access>
      <use-mappings>true</use-mappings>
      <method-access-level>remote</method-access-level>
   </access>
.....

Next you will need to adjust the access rights within the CFC function definition. Placing in whatever access level has been defined within the Remoting-config.xml. Flex can can access functions that are both remote or public. This CFC server side can just be a simple database query, so long as the function returns data to populate the data grid. The CFC in this example performs a query on a table within a defined data source. If you wanted to do the same, simply create a table within MYSQL or MSSQL and set it as a data source within the ColdFusion administrator.

Destination.cfc
<cffunction name="GetData" access="remote" returntype="query">


Configuring FusionDebug

Start up Eclipse with the FusionDebug Plug-in installed. Create a new Debug Configuration (Run->Debug Configurations…) for FusionDebug and configure the debugging port for your app server. In the IP Restrictions enter the IP address(es) of the server(s) that you want breakpoints to fire for. This means that when the request originates from one of the IP addresses you’ve entered it, the breakpoint should fire but for other requests the breakpoint will be ignored.

You then will have to navigate to the Source Code Lookup tab. Here you will simply need to select the project you want to debug and reference it’s source in the directory. Add the lookup and you are ready to start debugging.

Start debugging by pressing the Debug button at the bottom of the debug configuration screen. Once the debugger is attached open the CFC and add some breakpoints where you want to stop execution of the code.

Now run your Flex application up and make a request from an IP address that is in the list of IP Restrictions. FusionDebug halts the activity for only the flash remoting requests whose IP addresses have been entered into the IP filter, so if you make a request for a different machine then the breakpoint doesn’t fire. If you are using an app server on your local machine, CF8 and CF9 use loopback addressing and as a result uses the Ipv6 address 0:0:0:0:0:0:0:1 for localhost if you are using Windows Vista or 7 operating systems.

Whereas request from clients that are not in the IP restrictions list run to completion without the breakpoints firing! That’s Non-Intrusive Debugging!


Messaging Gateways

Below is a short example of testing the non-Intrusive debugging functionality in regards to ColdFusion Gateway messages.

Create a Flex project with a main mxml that contains a script block with a function that creates a producer and consumer object along with event listeners and remote destinations.

MessagingGatewayTest.mxml
import mx.messaging.Consumer;
import mx.messaging.Producer;

private var publisher:Producer;
private var subscriber:Consumer;

private function createChat():void
{
   publisher= new Producer(); 
   publisher.addEventListener(MessageFaultEvent.FAULT, producerFault);
   publisher.destination = "ColdFusionGateway";

   subscriber= new Consumer();
   subscriber.addEventListener(MessageAckEvent.ACKNOWLEDGE, acknowledge);
   subscriber.addEventListener(MessageEvent.MESSAGE, receiveMessage);
   subscriber.destination = "ColdFusionGateway";
   subscriber.subtopic = "test";
   subscriber.subscribe();
}

The you will need to write a function for the handling of the acknowledgement event from the consumer, functions for sending and receiving messages and a function for handling a fault event from the producer.

MessagingGatewayTest.mxml
private function producerFault(faultEvent:MessageFaultEvent):void
{
   output.text += "[Error: " + faultEvent.message.toString() + "]\n";
}
private function acknowledge(ackEvent:MessageAckEvent):void
{
   output.text += "[Contact with the Consumer has been established.]\n";
}

private function sendChatMessage():void 
{
   var msg:AsyncMessage = new AsyncMessage();
   msg.body = input.text;
   msg.headers["uname"] = "tester";
   msg.headers["gatewayid"] = "flexgateway";
   publisher.subtopic = "test";
   publisher.send(msg);
   input.text = "";
}

private function receiveMessage(msgEvent:MessageEvent):void
{
   var msg:AsyncMessage = AsyncMessage(msgEvent.message);
   output.text += msg.headers["uname"] + ": " + msg.body + "\n";
}

Within the content root of your CF app server (a.k.a wwwroot folder) you should place the CFC that you are using to interact with. This will contain a function that will return a message to the caller via the same destination and channel.

InterceptFlex.cfc
<cfcomponent output="false">
   <cffunction name="onIncomingMessage" returntype="any">
         <cfargument name="event" type="struct" required="true" />	 
	  <cfscript>
		x = structNew();
	        x.body = "Hello Friend";
		x.destination = "ColdFusionGateway";
		x.headers = structNew();
		x.headers['uname'] = "system";
		x.headers['DSSubtopic'] = "test";
		x.lowercasekeys = "yes";
      </cfscript>
   <cfreturn x /> 
 </cffunction>
</cfcomponent>

Some changes that may need to be made to CF8 and CF9 Application servers’ configuration before Flash Gateway usage, the first being within the corssdomain.xml file, make sure the contents allows all domain policies, all domains and all ports. Obviously there would be security issues with the following changes, but since this is just an example of Flash Remoting we will allow all ports and domains, but in reality these should be appropriately restricted.

crossdomain.xml
<cross-domain-policy>
   <site-control permitted-cross-domain-policies="all" />
   <allow-access-from domain="*" secure="false" to-ports="*"/>
   <allow-http-request-headers-from domain="localhost"/>
</cross-domain-policy>

Within the messaging-config.xml set the server properties as shown below within the destination “ColdFusionGateway” properties.

messaging-config.xml
<destination id="ColdFusionGateway">
   <adapter ref="cfgateway" />
      <properties>		
         <server>
            <durable>false</durable>
            <allow-subtopics>true</allow-subtopics>
         </server>
.....

A subtopic is a property of both the producer and consumer components, within the xml you are configuring the destination “ColdFusionGateway” to allow the subtopic to be used as a message destination. Setting the server configuration durable to false allows for messaging without the JMS (Java Messaging Service) API. If you are running Flex server with ColdFusion comment out the “host=localhost” line within the flex-messaging-gateway config file. This is located within the root ColdFusion directory \gateway\config\, else if Flex is on this machine but not installed as part of ColdFusion specify localhost.

You can configure your app server gateways for CF8 and CF9 as shown below in order to create the appropriate gateway needed for this example:

CF8

CF9

The counter of your Gateway should be 0 before the test has been executed. After the test is run both the ‘in’ and ‘out’ counter should display one message each in their fields (The in-going message being the call for the CFC via the ColdFusion channel. The outgoing message being the response from the CFC I.E. the body of the cfscript) When the program is first launched you should see the confirmation of contact from the Consumer.

Once some message has been entered, you should then see the message coming from the CFC.

FusionDebug halts the process of the CFC for specific users listed within the IP Restriction configuration options. All IP’s not entered within the filtering box will simple run the app as normal.


Conclusion

The non-Intrusive debugging feature ultimately provides a development team with the ability to debug their code without affecting other team members. It could even be that you need to debug a request from a specific client because they are the only one that experiences a problem. Non-Intrusive debugging can be used here to filter the requests that fire the breakpoints to only the problem client. This results in saving time and allowing bugs to be spotted earlier on within the development stage of production and can also lead to decreasing time consumed by debugging newly implemented components.

Source Code: FD128source.zip

Issue Details

Type: DevNet
Issue Number: FDS-128
Components: Breakpoints
Environment:
Resolution: Fixed
Added: 10/11/2010 11:45:34
Affects Version:
Fixed Version: 3.5
Server:
Platform:
Related Issues: None

[FDS-130] FusionDebug: Feature Focus – Non-Intrusive Debugging

Description

Non-Intrusive Debugging

Non-Intrusive debugging has been introduced in FusionDebug 3.5, which allows breakpoints to only fire when requests are coming from a specified IP address. This makes it possible for a developer to debug and set breakpoints against a central server, leaving the system untouched and unaffected for everyone else.

This article will cover how to configure and use Non-Intrusive Debugging, the underlying implementation and a few tips on what to do if your breakpoints don’t fire when they are supposed to. The last section will also talk about the limitations of the Non-Intrusive Debugging feature in FusionDebug.

Configuration

Non-Intrusive Debugging can be enabled on any new or existent Debug Configurations in FusionDebug 3.5. This is done by entering the IP addresses to break on in the IP Restriction section available in the Connect Tab of the Debug Configuration to edit.

The IP Restriction feature in FusionDebug supports both IPv4 and IPv6 addresses, but there is no input validation so make sure these are entered correctly using standard IPv4 and IPv6 formats.

So for example say you only want breakpoints to fire when connecting locally, then you can enter 127.0.0.1 if connecting using IPv4 and 0:0:0:0:0:0:0:1 if using IPv6.

Multiple IP addresses can be specified by using a comma (,) to separate them, so in the previous example we can make sure that the breakpoints fire when connecting locally using either IPv4 or IPv6 by specifying them both like this: 127.0.0.1, 0:0:0:0:0:0:0:1

An example of this can be seen in the image below.

After the Non-Intrusive Debugging settings have been entered, click Apply to save the setting to the configuration. Please note that the debug session will have to be re-launched for the new IP Restriction properties to take effect.

Under the hood

When a request is made to the server being debugged in FusionDebug the connected IP address is compared to the ones entered in the Debug Configuration of the launched session.

FusionDebug does this by evaluating the CGI.REMOTE_ADDR variable for the request with the ones specified in the Debug Configuration screen. If the cgi.remote_addr variable matches any of the ones entered the breakpoints will fire as usual, otherwise they will not.

It is important to understand that FusionDebug can only evaluate the value that the ColdFusion server has stored. For example if the connection to the server is going through a proxy, FusionDebug will compare the IP address of the proxy and not the end user’s.

Also the entered IP addresses must exactly match the value of the cgi.remote_addr variable, no wildcards are allowed. For example you cannot enter 192.168.1.*, you will have to specify all the exact IP addresses to break on.

Adobe ColdFusion and Railo servers might also deal with different connection types differently and the value of cgi.remote_addr might differ slightly from server to server.

It is important to know that if the cgi.remote_addr variable cannot be evaluated, i.e. it has not been set properly, Non-intrusive Debugging will not function.

My breakpoints don’t fire

If you have enabled Non-Intrusive Debugging but the breakpoints do not fire or behave in the way you are expecting them to do, here are a few trouble-shooting tips.

IP addresses correctly entered

Make sure that the IP addresses to break on are specified correctly in the Debug Configuration using standard IP address notation and that no extra commas or dots have been introduced. Also make sure that the debug configuration settings have been saved.

IPv4 and IPv6

Make sure that you have not entered an IPv4 address when in fact the IP address reaching the server is an IPv6. Please note that different computers and operating systems will send different addresses depending on the network configuration. For example Microsoft Windows 7 has IPv6 enabled by default.
Also be aware that various servers will support different IP versions.

For example localhost can be specified as both an IPv4 and IPv6 address:
IPv4: 127.0.0.1
IPv6: 0:0:0:0:0:0:0:1

To be sure that the breakpoints fire on either the IPv4 or the IPv6 address both can be specified in the IP Restriction configuration, as in the image above.

Re-launch the debug session

It is not enough to just apply the new Non-Intrusive Debugging settings for the active Debug Configuration, but the actual debug session in FusionDebug has to be re-launched. This is because the IP Restriction properties are applied to the debug session at launch and cannot later be edited.

Inspect CGI.REMOTE_ADDR

If Non-Intrusive Debugging has been set up correctly but breakpoints still do not fire when they are expected to, a good thing is to actually check what value the cgi.remote_addr variable has been given.

One way to this is to have a CFML page containing this example code:

<cfoutput>remote_addr: #cgi.remote_addr#</cfoutput>

This will output the value of the cgi.remote_addr variable so that you can compare it to the ones entered in the Debug Configuration.

Another way is to inspect the value of cgi.remote_addr using FusionDebug. To do this you will have to disable Non-Intrusive Debugging by removing all the IP addresses in the Addresses field in the IP Restriction section of the Debug Configuration screen.

Once this has been done, apply the settings and re-launch the debug session and set a breakpoint on a page. Request this page from the machine you wish to enable Non-Intrusive Debugging for and the breakpoint should fire as normal.

You can now inspect the value of CGI.REMOTE_ADDR by selecting the Variables view tab in FusionDebug.

For Adobe ColdFusion:
Select the APPLICATION, REQUEST, SESSION, SERVER, CGI… Variable scope.
In this scope select CGI and scroll down the list of variables and locate the variable called REMOTE_ADDR.

For Railo:
Select the cgi Variable scope and scroll down the list of variables and locate the variable called remote_addr.

You can now copy the value of this variable and paste it in the Addresses field in the IP Restriction section of the Debug Configuration screen.

Proxy servers

If there is a proxy server between the user making the request and the server running ColdFusion, the value of the cgi.remote_addr variable will be set with the IP address of the proxy server and not the actual end user’s. This can create problems if there are multiple machines behind a proxy server and you only wish to break on a specified local IP.

Clear existent breakpoints

If breakpoints still do not fire when they are supposed to or behave in an unexpected way, it is a good idea to go to the Breakpoints view tab and delete all of the existent breakpoints and re-add them.

Sometimes breakpoints from an older version of FusionDebug will not work properly in a newer version, also if there is one bad breakpoint it might cause issues for other enabled breakpoints.

Limitations

There are many ways a request can be made to a ColdFusion server, for example http, flash remoting, web services, messaging gateway and more. We have tested FusionDebug using several different requests types and there is a DevNet article available covering this in more detail, “Debugging Flash Remoting and Gateway Messaging”.

As the Non-Intrusive Debugging feature in FusionDebug uses the value of the cgi.remote_addr variable for the request there will be cases when this variable is not being set and can therefore not be evaluated.

If you have specified IP addresses to filter breakpoints on and cgi.remote_addr doesn’t actually contain a value the breakpoints will not fire as FusionDebug would not know where the request came from.

Issue Details

Type: DevNet
Issue Number: FDS-130
Components: Breakpoints
Environment:
Resolution: Fixed
Added: 11/11/2010 09:48:50
Affects Version: 3.5
Fixed Version: 3.5
Server:
Platform:
Related Issues: None

[FDS-118] OnDemand Seminar: FusionDebug Introduction (with Railo)

Description

Using An Interactive Debugger To Increase Productivity

This recorded webinar reviews how to install FusionDebug and configure it for use with a Railo server in addition to discussing the many features FusionDebug offers.

Webinar Outline


  • Installing FusionDebug



    • Connecting FusionDebug with Railo



  • FusionDebug Feature Run-Down



    • Supported Platforms
      • ColdFusion 6, 7, 8 (Std/Ent/Dev), 9
      • Railo 3.1.x
      • Eclipse: 3.1, 3.2, 3.3, 3.4, 3.5, 3.6
    • Conditional Breakpoints
    • Break on Runtime Exceptions
    • Run to Line
    • Advanced Stepping Technology
    • Source Code Lookups
    • View Variables and Scopes (including queries)
    • Expression Watcher
    • Multiple Request Support
    • Full Stack Traces (including function arguments)



  • Summary

Watch Webinar

FusionDebug Introduction (with Railo) – Part 1 of 6
FusionDebug Introduction (with Railo) – Part 2 of 6
FusionDebug Introduction (with Railo) – Part 3 of 6
FusionDebug Introduction (with Railo) – Part 4 of 6
FusionDebug Introduction (with Railo) – Part 5 of 6
FusionDebug Introduction (with Railo) – Part 6 of 6

Get Started Debugging

Download a free trial of FusionDebug

About FusionDebug

FusionDebug is the fastest interactive step debugger for CFML and supports multiple engines (ColdFusion and Railo).

Issue Details

Type: DevNet
Issue Number: FDS-118
Components: API
Environment:
Resolution: Fixed
Added: 12/11/2009 12:10:45
Affects Version: 3.0
Fixed Version: 3.0
Server:
Platform: Solaris, MacOS, Windows 7, Linux, Windows 2008, Windows 2003, Windows Vista, Windows 2000, Windows x64, Windows XP, AIX
Related Issues: None

[FDS-125] Configure FusionDebug 3 for use with Railo 3.1 on Tomcat

Description

Introduction

I ran into a situation while working on a MachII application running on Railo 3.1 where I REALLY need to see what was going on with the various variable scopes during the request cycle, so I decided tonight to see if I could get FusionDebug 3 Beta up and running with Railo and Tomcat.

For the past couple of months, I’ve been running my CFML server engines (yes engines, plural) on top of Tomcat on my local development environment. This offers me, as an independent developer that works on a number of different client projects, a great deal of flexibility in matching a particular client’s production configuration. Also lately, I’ve been working on a couple of projects using Railo 3.1 as well as a project for a client that still uses CFMX 7. One of the things that I really missed when not developing with ColdFusion 8 is the step debugger that ships with CF8. I’d used FusionDebug some time ago with CFMX 7 when I was running it on top of JRun 4 but had never gotten around to getting it configured under my current, Tomcat-based setup.

Environment

Before we get started, I want to detail my particular setup and lay out some assumptions. My environment consists of the following components. Yours might be slightly different, but the basics should be the same.

  • Apache 2.2.11 web server configured with one virtual host per client site
  • Tomcat 6 installed into /opt/tomcat
  • Apache forwards ColdFusion requests to Tomcat via AJP
  • http://localhost web root is /Users/dskaggs/Sites/localhost/htdocs
  • WEB-INF folder from exploded Railo 3.1 WAR file resides in the web root folder

Now for some assumptions:

  • You can browse to a CFML page (either by going directly to Tomcat http://localhost:8080/someContext/test.cfm or through Apache http://localhost/test.cfm )
  • You’ve installed FusionDebug into Eclipse using the instructions in the “Install FusionDebug into Eclipse” section here
  • You’ve created a project in Eclipse that points to your site files
  • You don’t have Tomcat starting as a daemon or Windows service



Setting up Tomcat

The first thing that you have to do is tell Tomcat to enable debugging on a specific TCP port. For this example the port number that we’re going to use is 8000 (the same as the documentation on the FusionDebug site). You do this by adding the following line of code to the catalina.sh file in the /bin folder under the Tomcat install directory (in my case /opt/tomcat/bin/catalina.sh). I added it directly under the large comment block at the top of the file.

CATALINA_OPTS=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000

If you’re on Windows, this file is named catalina.bat and the format is slightly different:

set CATALINA_OPTS=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000

Save the file and launch Tomcat. In my case, I launched it in a terminal window so I could see exactly what was going on using the command:

cd /opt/tomcat/bin
sudo ./catalina.sh run

If everything worked correctly, you’ll see the following line near the top of the output to the console:

Listening for transport dt_socket at address: 8000

That concludes the configuration necessary on the Tomcat side.

Configuring FusionDebug

Now we need to get FusionDebug configured to connect to that port. In Eclipse, go to Window > Open Perspective > Other and choose FusionDebug from the list that appears in the popup window.

Then you’ll need to open up the Debug Configurations panel by going to Run > Debug Configurations. Find the entry for Fusion Debug in the left side, right click on it and choose “New” from the context menu. Enter a descriptive string in the Name: block at the top of the left side of the screen (I used simply Localhost). Then move to the configuration panel below with the 3 tabs (Connect, Source Code Lookup, and Common).

On the connect tab, enter localhost in the Host: block and 8000 in the Port: block.

On the Source Code Lookup tab, in the drop list that says “<All Projects>”, choose the Eclipse project that contains your files. In the drop list just to the right of the Project select box you just clicked on, choose the folder that corresponds to the web root of your site. Finally, enter the full file system path that corresponds to the folder you just chose and click the Add button. Click the Apply button to save the configuration. You can then click the Debug button at the bottom of the screen to start the debug session. If all goes well, you’ll see “FusionDebug (localhost:8000) (Connected)” in the Debug pane.

Testing

Now it’s just a matter of creating a test.cfm file (or using an existing file), setting some breakpoints and browsing to the file and you should see the execution stop at your breakpoint and be able to browse through the list.

Issue Details

Type: DevNet
Issue Number: FDS-125
Components: Connector for Railo
Environment:
Resolution: Fixed
Added: 11/01/2010 16:17:15
Affects Version: 3.0
Fixed Version: 3.0
Server:
Platform:
Related Issues: None

[FDS-121] FusionDebug: Feature Focus – Breakpoint Conditions & Hitcounts

Description

Breakpoint Conditions & Hitcounts

FusionDebug breakpoints now have conditions and hitcounts, further controlling when they fire. This article will demonstrate these features.

Conditional Breakpoints

Introduced in FusionDebug 3.0, conditional breakpoints allow you to halt an application when a certain condition evaluates to true. For example, in a loop you could use a conditional breakpoint to halt when a variable equals a specified value. The condition used can be any form of CFML expression, anything that can be used in a <cfif> tag can be used as a condition. Advantages of conditional breakpoints include:

  • Less time debugging; No need to step through long loops to get to a particular iteration.
  • Prevents convolution of production code with debug code. To stop on an iteration or when a condition evaluates to true without conditional breakpoints you would need to add <cfif> tags to your code and set a breakpoint in the body of the tags. One of the advantages of a debugger is the alleviation of extra code for debugging purposes.
  • Removes the need to disable breakpoints for some test cases, for example you might only want to stop a page on some specific input.

An Example

Given the following code:

<cffunction name="DoSomethingWithLastName">
	<cfargument name="lastname" type="string">
	<!--- Do something with last name arg --->
</cffunction>

<cfquery name="qry" datasource="test1">
	SELECT last_name FROM emp
</cfquery>

<cfloop query=qry>
	<cfset DoSomethingWithLastName(qry.last_name)>
	<cfoutput> #qry.last_name# <br> </cfoutput>
	<cfflush>
</cfloop>

Suppose we knew there was a bug somewhere in the “DoSomethingWithLastName” function, and we knew it happened when the last name of “Smith” was used as an argument. We could add a breakpoint on the line of the call to the function and set the following breakpoint properties:

This means that the breakpoint will only fire when qry.last_name equals “Smith”. If we now run the page, we see this:

The page has stopped on row 9 of the query loop, where the last_name field equals “Smith”. We can now step into the function and find the cause of the bug. Note that this is a relatively small query but could be thousands of rows. Using a non-conditional breakpoint in this scenario is time-consuming and unfeasible, plus you could end up resuming past the row that contains “Smith”.

Other useful examples of breakpoint conditions:

  • isdefined(“url.length”) and (url.length + 1) gt 10. This can be used to halt the page when certain url parameters are used, in this case length > 10.
  • DateCompare(yourdate, CreateDate(2009, 01, 01)) LTE 0. This will halt the page when “yourdate” is before 1st January 2009.
  • http.remote_addr eq “127.0.0.1” or http.remote_host eq “localhost”. These conditions will allow another machine to request the file without the breakpoint firing. Useful if you have to demo the file to another person but don’t want to disable your breakpoints. Note, on Railo use cgi.remote_addr eq “127.0.0.1”.

Read more about Conditional Breakpoints

Hitcounts

New to FusionDebug 3.0.1 are Breakpoint Hitcounts. Hitcounts are a specific type of condition for a breakpoint separate from an actual breakpoint condition. A breakpoint with a hitcount will only fire after a certain amount of hits. This is useful if you have no variables to use in a condition.

Hitcounts can be used along with conditions to fine tune the firing of the breakpoint. For example consider the following loop over a query variable:

5: <cfloop query="qry">
6:     ... use data from qry
7: </cfloop>

If a breakpoint was on line 6 we could use a hitcount of 15 and a condition of “qry.last_name eq ‘Smith'”, shown here:

This would stop the page on the 15th row that had the last_name field equal to “Smith”

Read more about Hitcounts

Conclusion

These two features will cut your debugging time down by letting FusionDebug work for you, evaluating conditions that would otherwise need to carried out by yourself, watching the Variables or Expressions view for changes. Most modern debuggers support Conditional Breakpoints and Hitcounts because as applications become more complex, debugging them becomes more complex and in response debuggers must relieve some of this complexity. These two features and countless others do just that.

Other Articles You Might Be Interested In

FusionDebug: Feature Focus – Auto-step

Useful Links

Download FusionDebug 3.0.1 (free trial version available)
FusionDebug Feature Focus

Issue Details

Type: DevNet
Issue Number: FDS-121
Components: Breakpoints
Environment:
Resolution: Fixed
Added: 30/11/2009 13:41:23
Affects Version: 3.0.1
Fixed Version: 3.0.1
Server:
Platform:
Related Issues: None

[FDS-122] FusionDebug: Feature Focus – Auto-step

Description

Auto-step

New to FusionDebug is the Auto-step feature. Interactively watch your code being executed at a specified speed.

The new Auto-step feature adds even more interactivity, enabling you to view execution paths of your application, variable / expression changes and even root out bottlenecks in your code.

Using Auto-step

You can set an interval between step operations in the FusionDebug Configuration dialog shown here:

There you can set intervals for both auto-stepping into or over.

You control auto-stepping with two toggle buttons on the Debug View toolbar, shown here:

The button on the left is Auto-step Into, the right one is Auto-step Over. Only one can be toggled at any time so toggling on Auto-step Into when stepping over will cause Auto-step Over to be toggled off.

How Auto-step helps

Auto-step can be used in a number of interesting ways:

  • By setting a moderately high stepping interval you can visibly watch the path of execution your application takes. This is very powerful as many bugs are simply code you think is being executed when in actuality it isn’t.
  • By setting a high interval, say 500ms – 1000ms, you can watch the Variables / Expressions view and for any changes that should or should not be happening.
  • By setting a low interval (lowest 20ms) you can visibly see what parts of your code are taking a long time to complete. If there are long pauses between steps (longer than the step interval you entered) you know that the line should be investigated, if need be.
  • Auto-step could also be used for entirely other purposes than debugging. For example, introducing a new developer to an application and it’s code can be time consuming and consequently expensive. By using Auto-step with an appropriate interval, the developer can watch where the execution path goes and learn what is being done and where.

Other Articles You Might Be Interested In

FusionDebug: Feature Focus – Breakpoint Conditions & Hitcounts

Useful Links

Download FusionDebug 3.0.1 (free trial version available)
FusionDebug Feature Focus

Issue Details

Type: DevNet
Issue Number: FDS-122
Components: Stepping
Environment:
Resolution: Fixed
Added: 30/11/2009 16:28:34
Affects Version: 3.0.1
Fixed Version: 3.0.1
Server:
Platform:
Related Issues: None