Consider moving to amqplib

[michaelklishin]

I'm not sure why node-amqp is used in Starsky but it's a largely unmaintained client that is known to have opinionated features that do more harm than good.

Consider moving to amqp.node which is maintained much better and now also has a callback API in addition to futures.

Thank you for your time.

[gjohnson]

I originally went with node-amqp because there are plenty of production users and with myself not having much rabbit/amqp experience at the time, I relied on that fact to help make my decision. However after understanding rabbit/amqp a bit more now, I completely agree with you and have plans to switch over.

I will leave this open until I make the switch.

Thanks for the input!

[hazeledmands]

👍 I think this is a great idea. I would be happy to help with this.

[gjohnson]

Go for it. I've been a bit busy but I do think it's a much more stable/sane implementation.

Only requirement is to keep our API intact. Feel free to use their promise or callback API internally though.

[sherrman]

amqp.node doesn't expose when it heartbeat information. It emits an error when there is no response or data to two consecutive heartbeat periods.

Is that break from the API no good for you?

If you supply a non-zero period in seconds as the heartbeat parameter, the connection will be monitored for liveness. If the client fails to read data from the connection for two successive intervals, the connection will emit an error and close. It will also send heartbeats to the server (in the absence of other data).