WebSphere Message Brokers
File: au16612_
Writer: Jane Brockbank Task topic This build: July 31, 2007 21:39:42
Resolving problems when debugging message flows
This topic contains advice for dealing
with some of the common problems that can arise when debugging message flows.
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.
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.