2

IronMQ supports push queues, but the example Heroku push queue subscriber is implemented as a web dyno. This feels awkward, because I need a single Heroku project to use web dynos that serve web requests, and worker dynos that process time-consuming needs. That's how Heroku is designed.

The IronMQ API indicates that the push queue subscriber should be accessible via a publicly-accessible URL; that's why web dynos are necessary.

Is there any (clean) way to get IronMQ push queues publishers and subscribers within a single Heroku project?

Is there another queue service that does support something like this (even long-polling subscribers would work)?

Jacob Marble
  • 28,555
  • 22
  • 67
  • 78

1 Answers1

2

If you wanted to use IronMQ from a non-web-accessible server, my best advice would be to use pull queues. Start up your worker dyno, and have it pull down any messages available every X seconds. With 10 million requests free, you're only using 26% of the free quota if you check for messages every second.

If you still wanted to do push queues and had a TCP port listening on the worker dyno, you could always use the push queues and have each message start up a worker on IronWorker that translates the message into a TCP connection instead of an HTTP connection.

Hope that helps!

Paddy
  • 2,793
  • 1
  • 22
  • 27
  • 1
    I guess 26% isn't much. Any plans to implement long-poll or another pseudo-push mechanism for Heroku users? – Jacob Marble Mar 13 '13 at 16:07
  • None at the moment. I'll bring it up with the team and see what we can do for the next iteration on the API. :) If you want to, you can open an issue at https://github.com/iron-io/issues/issues and we'll update it if we decide to implement this. – Paddy Mar 13 '13 at 16:10
  • Ok. But how would you connect to a worker dyno through TCP? Need another addon? – noBillSide Jun 24 '13 at 14:46