0

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?

ux.engineer
  • 10,082
  • 13
  • 67
  • 112

1 Answers1

1

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:

enter image description here

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

Travis Reeder
  • 38,611
  • 12
  • 87
  • 87
  • It's an another issue when your service is unresponsive... Here we would need to deal with failing pushes where the tasks won't reach Iron.IO's servers in the first place. – ux.engineer Mar 04 '15 at 17:17
  • Oh, so you're talking about posting messages to IronMQ, not IronMQ Push Queues posting to your service? – Travis Reeder Mar 04 '15 at 20:26
  • Yes, using Iron Push Queue or the regular Pull Queue – either way the problem scenario here is pushes not reaching Iron at all. – ux.engineer Mar 05 '15 at 07:26
  • 1
    You could try posting to another cloud if one endpoint isn't responsive: http://dev.iron.io/mq/reference/clouds/ – Travis Reeder Mar 05 '15 at 23:39