Java class error messages are displayed when you start the debugger
Scenario: You are trying to start the debugger on a message
flow, but the debugger does not start, and a number of event errors are issued
about Java classes.
Explanation: The most likely cause of this problem is that
you have not installed the IBM Agent Controller. Although the Agent Controller
is not a prerequisite for WebSphere
Business Integration Message Broker, it is
a prerequisite for the message flow debugger.
Solution: Install the Agent Controller.
An endless "waiting for communication" message 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 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 workbench Event
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.
The debugger seems to stop
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: There are two possibilities.
The message flow might have encountered a time-intensive operation, such
as a huge database query that you simply have to wait for.
The broker ended, or some other extraordinary condition occurred, and
communication was lost. In this case, click Cancel to
stop the debug session.
The session ends abnormally while debugging
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 broker's execution group. You are concerned that this is going
to affect the operation of the flow, and want to put the execution group 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 below,
because the performance of message processing might be affected.
Solution: Redeploy the broker.
A full redeploy
of the broker should replace the orphaned flow with the original message flow.
If this has no effect, remove the orphaned flow from the execution group,
deploy, and then add the flow and deploy to restore the original state of
the broker as it was before the debugging session.
An error message is displayed indicating that the IBM
Agent Controller is
not installed
Scenario: You are using the message flow debugger and an
error is issued indicating that the Agent Controller is not installed, or
that you have chosen the wrong hostname or port. You have the Agent Controller
service started, and the hostname and port are valid.
Solution: Close and reopen the workbench,
and retry the command. You can also try stopping and restarting the Agent
Controller service.
Message
flow engines are not available
for selection
Scenario: You open the Attach to the Message Flow
Engine wizard, but there are no message flow engines
listed for the host computer.
Solution: Close the wizard, restart IBM
Agent Controller on
the server computer, then open the wizard again.
You cannot see the list of execution groups
Scenario: Your IBM Agent Controller is started, your broker is
running, but you cannot see the list of execution groups in the Agent page
when you attach to the debugger.
Solution: Start your Agent Controller services before you
start the broker. Restart the Agent Controller and try to attach again.
You see the wrong execution group names in the Agent page
Scenario: You see the same execution group names in the
Agent page when you try to attach to the debugger.
Explanation: The IBM Agent Controller has not updated the agent list
since the last attempt to attach to the debugger.
Solution: Restart the Agent Controller to refresh the list.
Shared Memory Allocation Error on AIX
Scenario: Your IBM Agent Controller has started, your broker is
running, and you see an error message saying that shared memory allocation
has failed after the broker is attached to the Agent Controller.
Explanation: This is a general timing problem that occurs
when the Agent Controller is connected to the broker when the broker has not
started completely.
Solution: Wait until the broker has started completely before
attaching it to the Flow Debugger. Alternatively, set the logging level in
the Agent Controller to debug or information; this allows more time for the
broker to start up. The following steps show you how to change the logging
level.
Go to the IBM Agent Controller install dir/config directory
and open the configuration file serviceconfig.xml.
Change the loggingLevel tag to debug or
information. The default value is warning.
The debugger does not pause at the next breakpoint
Scenario: The message flow debugger does not pause at the
next breakpoint in your message flow.
Solution: Perform the following checks:
Check whether your DataFlowEngine is running; if it is not,
restart it.
Check the input queue. If your input queue has the leftover
messages from the previous time that you used the debugger, clear them before
you send a new message.
The message does not stop executing at any breakpoint
Scenario: The message does not stop executing at any breakpoint
after you attach to the debugger.
Explanation: This could be a timing problem or
you might have set the wrong parameters for the debug session..
Solution: Perform the following steps.
Check your launch configuration settings, ensuring that you
have specified the correct Flow Project, HostName and Flow Engine for the
debug session.
Restart the debug session.
Editing problems occur in the Message Flow editor
Scenario: Editing problems occur when you are using the
Message Flow editor while debugging a message flow.
Solution: Do not attempt to edit the message while the flow
debugger is attached. To edit a message flow, detach the debugger, edit the
message flow, and then redeploy the message flow.
Editing the MQ message descriptor (MQMD) causes unexpected behavior
in the debugger
Scenario: You edit properties of the message MQMD descriptor
in the Message Set editor, but this causes unexpected behavior in the debugger.
Explanation: If you edit the content of the MQMD descriptor,
these fields take a certain range of values. You need to know
these ranges before editing the properties. Unless you explicitly specify
the value of these fields, they take default values, and certain fields might
not have been specified in the message. The values in the fields that are
not set explicitly in the message are default values; do not change these
unless you are aware of their importance or the possible range of values.
You cannot see the message content when debugging your message flow
Scenario: You are using the message flow debugger, and you
can see the message passing through the message flow, but you cannot see the
content of the message.
Solution: Open the Flow Debug Message view by clicking Window > Show View > Other > Message Flow > Flow Debug Message, then OK.
You cannot see the message flow names in the Flow Debug
view
Scenario: You cannot see the deployed message flow names
in the Flow Debug view after attaching the debugger
to the execution group.
Solution:
Stop the broker on which the execution group is running.
Restart the IBM Agent Controller that is running on the same
computer as the broker.
Restart the broker.
You cannot see the deployed flow names in the Flow Debug
view
Scenario: You cannot see the deployed flow names in the Flow Debug view after attaching to the execution group.
Explanation: This could be a timing problem.
Solution: Wait until the broker has started completely and
try to attach the debugger again, or restart the IBM
Agent Controller that
is running on the same computer as the broker, then restart the broker.
You cannot change a message flow after debugging
Scenario: You were debugging, but now your message flow
seems to be stuck. When you put a new message in, nothing happens.
Explanation: This might be because a message was backed
out, but you have not set the Backout requeue
name property of your input queue.
Solution: Set the Backout
requeue name property to a valid queue name (such as the name of
the input queue itself) and your flow will become unstuck.
You redeployed a debugged message flow but deployment hangs
Scenario: You found problems in your message flow by using
the debugger. You changed your message flow and then redeployed it, but now
the deployment hangs.
Solution: Make sure that when you redeploy the flow to an
execution group, the execution group is not still attached to the debugger.
You cannot add a mapping breakpoint
Scenario: You cannot add a mapping breakpoint into the breakpoint
list. The execution does not stop at this breakpoint.
Explanation: Information to be provided
Solution: Information to be provided
You cannot remove a mapping breakpoint
Scenario: You cannot remove a mapping breakpoint from the
breakpoint list. The execution always stops at this breakpoint.