There should be an architecture in place to not have any push queue tasks lost while Laravel fails to communicate with IronIO servers.
For example there is IronIO service outages, or DNS hiccups along the way. Or as in our case, it seems our iron-io/iron_mq package had grown old and pushes started to give exceptions:
'Http_Exception' with message 'http error: 0 |
Problem with the SSL CA cert (path? access rights?)'
in /var/www/project/vendor/iron-io/iron_core/IronCore.class.php:346
gecbla has suggested catching exceptions, but how would you proceed from there?
try {
Queue::push('AddContent');
} catch (Http_Exception $e) {
Log::info('Queue::catch');
}
What would be best way to achieve a fallback, exception handling architecture?
There is a feature built in to IronMQ called Error Queues that will collect messages that couldn't be delivered into a separate pull queue so you can deal with them later. Here's a diagram showing how this works:
You can read more about it on the Iron.io blog here: http://blog.iron.io/2014/01/push-queues-error-queues-better-queue.html or in the docs here: http://dev.iron.io/mq/reference/push_queues/#error_queues