This topic contains advice for dealing
with some of the common problems that can arise when debugging message flows.
A timeout occurs before the Rational Agent Controller service can connect
Scenario: You see error messages indicating that the Rational® Agent
Controller service failed to start and that a timeout occurred before the Rational Agent
Controller could connect.
Explanation: The Rational Agent Controller might be
using the wrong version of the JVM.
Solution: Ensure that a supported JVM is being used. To
determine which JVM is being used, issue the java -version command
at the command line. To get the correct result, the java -version command
must call the Java™ executable file that was specified for use when
the Rational Agent
Controller was installed.
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 error could be caused by a timing problem,
or if you 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: While debugging a message flow, editing problems
occur when you are using the Message Flow editor.
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 Debug view
Scenario: You cannot see the deployed message flow names
in the Debug view after attaching the debugger to the execution group.
Solution:
Stop the broker on which the execution group is running.
Restart the Rational Agent Controller that is running on the
same computer as the broker.
Restart the broker.
You cannot see the deployed flow names in the Debug view
Scenario: You cannot see the deployed flow names in the
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 Rational Agent Controller that is running
on the same computer as the broker, and then restart the broker.
An exclamation mark appears above a node during debugging
Scenario: In the Message Flow editor, an exclamation mark
(!) is displayed above a node during debugging.
Explanation: An exception has occurred in the node during
debugging.
Solution: Look under the ExceptionList in the Variables view
of the Debug perspective to find out what error
has occurred.
The PutTime that is reported by WebSphere MQ on z/OS, and other times or timestamps are inconsistent
Scenario: The PutTime that is reported by WebSphere® MQ on z/OS®, and other times or timestamps are inconsistent.
A difference of approximately 20 seconds is detected in:
Traces (including that obtained from the Trace node)
The MQPUTTIME command timestamp in the message MQMD
header
Timestamps obtained from ESQL (for example, in a Compute node)
Explanation: WebSphere Message
Broker reports
the time using Coordinated Universal Time (UTC), which does not account for
leap seconds. However, on z/OS, the message
putTime that is reported by WebSphere MQ in the
MQMD header of a message does account for leap seconds, using the value
specified for the number of leap-seconds in the CVT field.
This
inconsistency can cause:
Problems when debugging
Problems with message flows if you use timestamps to control the flow
of messages
Misinformation
Solution: Set the CVT field so that it is consistent with
the UTC leap seconds. Alternatively, add an offset to adjust a z/OS timestamp reading. For example, add
20 seconds when trying to get the CURRENT_TIME in ESQL.
The message does not stop processing at breakpoints
Scenario: Message processing continues when a breakpoint
is encountered.
Explanation: This error could be caused by a timing problem,
or if you have set the wrong parameters for the debug session.
Solution: Check your launch configuration setting. Ensure
you have specified the correct Flow Project, HostName and Flow Engine for
the debug session. Restart the debug session.
You cannot see where the debugger is in the message mapping editor
Scenario: The message mapping editor has opened in the toolkit,
but it is unclear where the debugger is in the map.
Explanation: The source lookup path for the message map
file is not configured correctly.
Solution: Check your debug launch configuration settings
and ensure you have configured the source lookup path for the message map
file correctly.
When debugging a message map, the debugger does not move to the next
field
Scenario: You are debugging a message map, and the debugger
does not move to the next field. You have to click the Step over button
multiple times.
Explanation: The source lookup path for the message map
file is not configured correctly.
Solution: Check your debug launch configuration settings
and ensure you have configured the source lookup path for the message map
file correctly.
When debugging a message map, the debugger does not move out of the
mapping node
Scenario: You are debugging a message map, and the debugger
does not move out of the message map.
Explanation: The source lookup path for the message map
file is not configured correctly.
Solution: Check your debug launch configuration settings
and ensure you have configured the source lookup path for the message map
file correctly.
The message flow stops at a collector node
Scenario: Message processing stops after selecting the
Step into Source Code icon on a Collector node.
Explanation: The collector node is a multithreaded node
and the thread is ended by selecting Step into Source Code.
Solution: Set a breakpoint manually after the collector
node.