This week we've updated nuntium to version 2.8, yay!
Aside from some minor bug fixes, nuntium now implements an exponential backoff strategy when a message delivery fails. Previously, it worked like this:
- A message failed to be delivered.
- If the cause was the message itself (for example it contains invalid data), it was discarded.
- If the cause was an authentication problem, for example an SMTP server's password changed, the channel responsible for delivering the message was disabled and an alert was sent to the administrator.
- Otherwise, the cause was a temporary one, maybe a connection timeout. In that case, delivery through that channel was suspended for five minutes with an alert being sent to the administrator.
In this last point, sometimes the cause was in fact an invalid message for which the other side expecting to get the message wasn't correctly prepared to handle. This caused all subsequent valid messages to be suspended for five minutes.
We changed this behavior to just suspend this message for some time (using an exponential backoff strategy) but allowing next messages to be sent. The message is marked as "delayed" an you can see it in the UI. We think this is a much more resilient solution.
The other big thing is that we changed the library we used to receive and send XMPP messages. Previously we used xmpp4r, which works quite well but sometimes it would raise unexpected exceptions which we couldn't understand. Also, it wasn't based on event machine. We switched to the excelent blather library and so far it didn't let us down.
What's next? Having implemented delayed messages on failure cases we are only a small step away from implementing delayed messages just for the sake of it. Imagine sending a message to nuntium and telling it to send it on a specific date. With this you could implement things as simple as birthday reminders to pregnancy checks reminders or messages sent today or tomorrow afternoon of a given time zone.