The widespread usage of the phrase “persistent queue” has a negative impact because people believe that queue attribute actually does something. It’s always worth taking time to stamp out usage of that phrase wherever we find it and I’ll attempt to explain why.
The problem with the term “persistent queue” is that it leads people to believe that the behavior attaches to the queue itself when in fact with WebSphere MQ message persistence is now and always has been an attribute of the individual message. Because of the widespread use of the term “persistent queue” and an incorrect belief about behavior of the queue based on that, some customers find that WMQ doesn’t behave as they expect, often to their detriment.
There are two rules for persistence:
- If the quality of message persistence is important, set it explicitly in the application.
- Whether or not a message is persistent is always important.
The only time that DEFPSIST should be relied on to actually affect message persistence is the odd case that message persistence needs to be externally settable at run time. The reasoning is that persistence (or not) is a design decision driven by a business requirement. The person responsible for implementing those business requirements is the development team manager who has the opportunity to explicitly choose the correct behavior. When that choice is abdicated and placed in the hands of the WebSphere MQ admins, separated by both distance and time from the actual business requirements, it doesn’t get managed to the original business requirements and that results in a brittle system.
One of my first assignments with IBM was a company who had been experiencing a network-wide WMQ outage for a couple of weeks. We determined that someone had changed DEFPSIST on a queue in a network that was tuned and designed for non-peristent messages. The result was an outage lasting almost 3 week. In another case a customer’s entire Message Broker service infrastructure went down in Production because someone decided that the transmit queue should be persistent. Immediately after the change all replies to TEMPDYN queues were shunted to the DLQ. Fortunately in that case the DLQ messages immediately told us what the problem was so the outage was of short duration.
The pervasive misunderstanding of the queue’s DEFPSIST attribute continues to cause outages and the external symptom of that misunderstanding is the use of the term “persistent queue.” For instance, during debugging people often report the setting of the queue as if that somehow reflects the persistence off the messages in the queue. “Where did my messages go? I have a persistent queue!” Of course there is no direct cause and effect there. The messages may have come through an alias or a QRemote where DEFPSIST(NO) was set. Or (hopefully) the application explicitly set the persistence that was required. I climb on this soap box whenever I hear the phrase “persistent queue” during debugging because DEFPSIST tells me nothing about whether the messages in the queue were actually persistent or not.
Many people who understand DEFPSIST quite well also use the term “persistent queue” simply out of convenience – it has entered the culture and it’s easier than saying “DEFPSIST on the queue is on”. It’s worth asking even those people to not use the term so that a) we can identify the people who need education; and b) so as not to perpetuate the misunderstanding of persistence that leads to brittle systems.
So…there is no such thing as a “persistent queue.” Only queues with DEFPSIST(YES), which contain messages that may or may or may not be persistent. Practice that discipline in your admin and programming teams and and you will find that the reliability of your systems improves over time.