I don't usually post non technical stuff on my blog but I would really like anyone living in Barcelona to know about my osteopath, Kathyn McConkey. I have had chronic neck and upper spine issues for years, and I have seen many physio therapists, including spine specialists, quiropractors and osteopaths. But none were able to help me. Then I found Kathrn McConkey and her Osteopatia del Mar practice three years ago and it changed my life for the better.
How to Make Your Messaging System Reliable and Keep Your Support Engineers Happy
When a messaging system lies at the heart of your application architecture you need to make it easy to respond to message processing failures. The more queues you have the more important a coherent incident response capability is. Unfortunately, it is all too common to see a chaotic policy or no policy at all for handling messages that cannot be processed successfully. Messages get delayed or lost on a regular basis and no-one is even sure how many.
The normal approach is to create a dead letter queue on a queue by queue basis and send messages there that cannot be processed. But what do you do from there? In this post we'll be looking at a message lifecycle baked into the messaging architecture that can solve this problem.
DSL Parser - Sample Code
I while back I wrote a blog series about DSLs, grammars, tokenizers, parsers and a SQL generator. The idea was that you could write a DSL query to mine your error log data and the code would generate SQL. The series can be found here: http://jack-vanlightly.com/blog/2016/2/3/how-to-create-a-query-language-dsl.
The tokenizer while simple was very inefficient, so I wrote a better one, you can find that here: http://jack-vanlightly.com/blog/2016/2/24/a-more-efficient-regex-tokenizer
I have just published working code based on this series and the better Regex tokenizer on Github here: https://github.com/Vanlightly/DslParser.