Any infrastructure architect will tell you that the most frustrating part of managing a system that relies heavily on an enterprise message queue is dealing with the failed messages that don't get processed, linger on the queue, and eventually get shuffled off to the recycle bin. While no systems engineer ever looks forward to dealing with failed messages, the failed message frown can be turned upside down by integrating those failed messages into an organization's Agile testing cycle.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Poisoned messages and the dead message queue
Every messaging system needs a dead message queue. Without one, the possibility exists that a poisoned message will sit on a queue unprocessed, jamming the flow of execution and stopping subsequent messages from getting handled. To alleviate such problems, every messaging system needs a dead message queue, also known as a poisoned message queue, where jobs that have failed to process, have malformed headers, or have simply sat on the queue for far too long, can be moved out of production and into a separate area for further inspection and possible debugging. Sometimes these messages are inspected manually. Sometimes small errors are corrected and the message is resubmitted to the queue. And sometimes these messages are just thrown into the recycle bin and discarded forever. However, a complimentary yet often overlooked strategy is to randomly add these messages to the queues in your testing environment and see how these types of problem packets are handled by the non-production system.
To alleviate problems, every messaging system needs a dead message queue.
Lukas Stewart, Enterprise Software Architect
Integrating Agile testing techniques
Developers are always trying to figure out creative ways to test their systems by thinking up weird, wonderful and idiotic ways that users might enter incoherent data into the system. Sadly, not matter how clever a developer is, they are never clever enough to really explore the depths of idiocy and incoherence to which their application clients are capable. Okay, that may be a little bit mean, but the fact remains that it is impossible for even the best testers to conjure up a test for every single way a system might be mistreated.
This is where the dead message queue as a testing technique comes in. Smart software engineers know that there is no better test on their system than the real, true to life problems and error to which clients subject the system. By using the jobs that have blocked the messaging infrastructure and caused real time production problems, software developers can take their craft one step closer to being robust enough to handle everything their clients can throw at it.
Do you have any creative and unique Agile testing techniques? Let us know about your strategies for developing better code.