Our neighbour’s son came up to me and said “I am a magician – look here is my trick”. The trick was a good trick, but then I had to explain that being a magician is more than doing just one trick.
I thought of this as I was reviewing some old note books and found the comments I made about a customer visit, and the “MQ architect and lead MQ programmer”.
This architect knew about Request-Reply and Fire-and-Forget, but he was missing other tricks.
The conversation went along the following lines
Messages processed in strict sequence
Me: Do your messages have a requirement to be strictly processed in sequence?
Him: I dont know, why?
Me:You can only have one putting application, one channel, and one application getting messages. If you have more than any of these – you can get messages processed in the wrong order.
Availability and scalability
Me: What response time requirements do you have for the end-to-end transaction?
Him: under 5 seconds
Me: If the back end queue manager goes down, how long does it take to restart?
Him:About a minute
Me: So one backend will not provide the availability you need.
Him: But we use clustering!
Me: On how many queue managers is the queue defined on?
Me: Do you use different clusters for online and batch traffic?
Me: To isolate traffic, and ensure that batch does not impact online, either in channel throughput – or filling up the System.Cluster.Transmit.Queue.
and so it went on.
One thought on “The one trick magician”