Resolving problems that occur when starting and stopping the debugger

Use the advice given here to help you to resolve common problems that can arise when you debug message flows.

An endless "waiting for communication" progress bar is displayed when you start the debugger

Scenario: After you click Start Debugging, you get an endlessly cycling progress bar entitled "waiting for communication". The "debug session started" message is not displayed in the information pane.
Explanation: If the message flow has nodes with ESQL statements, the flow might not deploy even if the statements are correct syntactically.
This situation can occur, for example, because of multiple declarations or uninitialized variables (that is, semantic problems that the syntax parser does not pick up).

Always check the IBM® Integration Toolkit Administration log to confirm that the debugged version of your message flow has deployed successfully; it has the same name as the original message flow, with the suffix _debug_.
If the message flow does not deploy properly, the debugger cannot establish communication with the flow, and you see the endless progress bar.
Solution: Click Cancel to clean up and return to a good state, then fix your errors and try again.
As a check, see if your flow can deploy without the debugger.

Scenario: You are debugging a message flow and continue after encountering a breakpoint. However, nothing seems to happen and after about a minute, a progress bar appears, indicating that the debugger is waiting for communication.
Explanation: This situation can occur for the following reasons:
- The message flow might have encountered a time-intensive operation, such as a huge database query, and you must wait for the flow to complete the action.
- The integration node ended, or some other extraordinary condition occurred, and communication was lost. In this case, click Cancel to stop the debug session.

Scenario: After debugging a message flow, the session ends abnormally and you still have the debug instance of the message flow (mf_debug_) deployed to the integration node's integration server. You are concerned that this is going to affect the operation of the flow, and want to put the integration server back to its original state.
Explanation: The orphaned message flow should behave as the flow would have done normally, and the Debug nodes have no effect on message processing.
If you have a small number of nodes in the message flow, corrective action makes no noticeable difference to the flow, apart from its name. However, if you have a large message flow (that is, more than 15 nodes or several subflows), take the corrective action described later in this section, because the performance of message processing might be affected.
Solution: Redeploy the integration node.
A full redeploy of the integration node should replace the orphaned flow with the original message flow. If this action has no effect, remove the orphaned flow from the integration server, deploy, then add the flow and deploy to restore the original state of the integration node as it was before the debugging session.

Scenario: You try to relaunch or invoke a new debug session but when you click the green Debug icon , an error message is displayed stating: Cannot launch this debug session.
Explanation: When you click Debug , it relaunches the last debug session. It fails if you have not created a debug session previously. It also fails if the integration node and integration server that were attached previously in a debug session are no longer running, or have been restarted; the session cannot be reattached without re-selection of the integration node and integration server process instance.
Solution:
1. Close the error message and click the arrow immediately to the right of the Debug icon.
2. Re-select or modify the integration node and integration server information from the previous debug launch configuration by clicking Debug in the menu and selecting the previous debug launch configuration. See Attaching the flow debugger to an integration server for debugging for more information.

Scenario: You are copying a message map into an application, library, or integration project and errors have appeared in the task list.
Explanation: The application, library, or integration project did not have the correct references set before you copied the message mapping.
Solution: These errors remain in the task list, even if you reset the project references immediately after copying. Therefore, you must perform a clean build of the application, library, or integration project.