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 Rational Agent Controller. Although the Agent Controller
is not a prerequisite for WebSphere 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 Rational 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.
Scenario: Your Rational 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 Rational 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 Rational 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.
An error message is displayed indicating that the debug session cannot
be launched
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 the Debug icon,
it re-launches the last debug session. It fails if you have not created a
debug session previously. It also fails if the broker and execution group
that were attached to previously in a debug session are no longer running
or have been restarted; the session cannot be re-attached without re-selection
of the new broker and execution group process instance.
Solution:
Close the error message and click the drop-down arrow immediately
to the right of the Debug icon.
Re-select or modify the broker and execution group information
in the previous debug launch configuration by clicking Debug in
the drop-down menu and selecting the previous debug launch configuration.
See Attaching to the flow engine for debugging for more information.
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.
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.
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.
Errors are generated when you copy a message map into a message flow
project
Scenario: You copied a message map into a message flow project
and errors appeared in the task list.
Explanation: The message flow project did not have the
correct references set before you copied the message mapping.
Solution: These errors will remain in the task list, even
if you reset the project references immediately after copying; you must perform
a clean build of the message flow project.