This topic contains advice for dealing with some of the common
problems that can arise when debugging message flows.
A timeout occurs while waiting for the Rational Agent Controller service
to connect
Scenario: You see error messages indicating that the Rational
Agent Controller service failed to start and that a timeout occurred while
waiting for the Agent Controller service to connect.
Explanation: The 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, this command must call the
Java executable file that was specified for use when the 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 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 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, then restart the broker.
There is an exclamation mark 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 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 agrees 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 executing at any breakpoint
Scenario: Message processing continues when a breakpoint
is encountered.
Explanation: This could be a timing problem, or you may
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.