WebSphere Message Broker, Version 8.0.0.7
Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS
See information about the latest product version
See information about the latest product version
Resolving implementation problems when developing message flows
Use the advice given here to help you to resolve some common problems that can arise when running message flows.
- Messages are directed to the Failure terminal of an MQInput node
- Error message BIP2211 is issued on z/OS by the MQInput node
- Messages enter the message flow but do not exit
- Your execution group is not reading messages from the input queues
- The execution group ends while processing messages
- Your execution group hangs, or ends with a core dump
- Your XSLTransform node is not working after deployment and errors are issued indicating that the style sheet could not be processed
- Output messages are not sent to expected destinations
- You experience problems when sending a message to an HTTP node's URL
- When using secure HTTP connections, you change a DNS host's destination but the broker is using a cached DNS host definition
- The TimeoutControl node issues error message BIP4606 or BIP4607 when the timeout request start time that it receives is in the past
- You are using a TimeoutControl node with a TimeoutNotification node, with multiple clients running concurrently, and messages appear to be being dropped
- Error message BIP5347 is issued on AIX when you run a message flow that uses a message set
- Error message BIP2130 is issued with code page value of -1 or -2
- The execution group restarts before an MQGet node has retrieved all messages
Messages are directed to the Failure terminal of an MQInput node
Error message BIP2211 is issued on z/OS by the MQInput node
Messages enter the message flow but do not exit
Your execution group is not reading messages from the input queues
The execution group ends while processing messages
Your execution group hangs, or ends with a core dump
- Scenario: While processing a message, an execution group either hangs with high CPU usage, or ends with a core dump. The stack trace from the core dump or abend file is large, showing many calls on the stack. Messages written to the system log might indicate "out of memory" or "bad allocation" conditions. The characteristics of the message flow in this scenario often include a hard-wired loop around some of the nodes.
- Explanation: When a message flow thread executes, it requires storage to perform the instructions that are defined by the logic of its connected nodes. This storage comes from the execution group's heap and stack storage. The execution of a message flow is constrained by the stack size, the default value of which differs depending on the operating system.
- Solution: If a message flow that is larger than the stack size is required, you can increase the stack size limit and then restart the brokers that are running on the system so that they use the new value. For information on setting the stack size for your operating system, see System resources for message flow development.
Your XSLTransform node is not working after deployment and errors are issued indicating that the style sheet could not be processed
Output messages are not sent to expected destinations
You experience problems when sending a message to an HTTP node's URL
When using secure HTTP connections, you change a DNS host's destination but the broker is using a cached DNS host definition
The TimeoutControl node issues error message BIP4606 or BIP4607 when the timeout request start time that it receives is in the past
- Scenario: When a TimeoutControl node receives a timeout request message that contains a start time in the past, it issues error message BIP4606 or BIP4607: The Timeout Control Node '&2' received a timeout request that did not contain a valid timeout start date/time value.
- Explanation: The start time in the message can be calculated by adding an interval to the current time. If a delay occurs between the node that calculates the start time and the TimeoutControl node, the start time in the message will have passed by the time it reaches the TimeoutControl node. If the start time is more than approximately five minutes in the past, a warning is issued and the TimeoutControl node rejects the timeout request. If the start time is less than five minutes in the past, the node processes the request as if it were immediate.
- Solution: Ensure that the start time in the timeout request message is a time in the future.
You are using a TimeoutControl node with a TimeoutNotification node, with multiple clients running concurrently, and messages appear to be being dropped
- Scenario: You are using a TimeoutControl node with a TimeoutNotification node, with multiple clients running concurrently, and messages appear to be being dropped. In the timeout request message, allowOverwrite is set to TRUE.
- Explanation: If multiple clients are running concurrently, and allowOverwrite is set to TRUE in the timeout request message, messages can overwrite each other.
- Solution: Ensure that different TimeoutNotification nodes that are deployed on the same broker do not share the same unique identifier.