Message Broker flow designers have to pass multiple hot spots every time their flow gets through the production box. The variants of these hotspots are breathtaking, as they make adjustments to their code and their environments and finally define the differences between the expectations and the reality.
Here in one of our upcoming WebSphere Support Technical Exchange (WSTE
) "Ask The Experts" web sessions, we are intending to address some of the flow designer's and administrator's general questions. Some of the sample questions that we plan to address are:
- How can message flow design adversely affect WebSphere Message Broker at an operational level and how can these problems be avoided?
Here we try to address long running flows holding out config operations, recursive looping exhausting the stack, excessive tree copying / caching leading to a large memory footprint. You might want to read Developing message flow applications in the information center prior to the web conference.
- What is the best way to find out why my message flow is slow or it is taking lots of CPU?
The answer will be to get one to look into the accounting and statistics to break down response/CPU times, particularly using Message Broker Explorer, and Javatm Health Center in the monitoring space; see Monitoring message flow performance for background information.
- What is the best practice for using my message flow as a webservice client to call other systems?
We often see people using broker to facade a webservice, they then have an exception in a SOAPInput or HTTPInput flow that is actually due to an issue with a web services request made mid-flow. We can talk about using the BIP messages, user trace and TCP/IP trace to identify where the problem is occurring.
- What are the pitfalls for using message flow monitoring to audit and monitor my message flows?
We will address some the pitfalls that we have seen due to many messages, and logging out the bitstream or the entire message contents. My previous webcast replay for Events_Based Messaging in WebSphere Message Broker V7 is good background.
- Does my webservice message flow work as designed in the multi-instance message broker?
You might have several questions about how to configure your webservice message flows in such a way that it works in multi- message brokers. We will discuss the options that you can explore; see Webcast replay: Checklist for Implementing High Availability using Multi-Instances in Message Broker V7.
- How do I ensure maximum startup performance on z/OS?
Here, some possible conversation topics could be: (a) mounting shared file systems on the local lpar to where the broker is starting, (b) mounting them read only and (c) the options to control different run time environments at execution group level within zOS V7 broker.
You can send your questions that would be of general interest to the message broker architects, administrators and users community by using the information provided in this item: Ask the Experts: WebSphere Message Broker - Message Flow Design Strategies And Usual Pitfalls