Is anyone maintaining this repo?

[simonmorley]

Seems a shame if this isn't the case?

Does anyone know what's going on? We've moved on server to amqplib after suffering random disconnects using this. Not sure if we should move the rest of the services off this.

Would be nice to know the score.

[carlhoerberg]

We at @CloudAMQP have offered to take over the maintenance of the repo, but @postwait was not at the time interested to pass it on.

[soggie]

We're making heavy use of this library as well, wouldn't mind to contribute. @postwait what do you think?

[zeusdeux]

We are using this in production as well. But if this sees no activity we are going to be shifting to solutions provided by @squaremo

[simonmorley]

We've already ported most applications to amqplib and are having a much better time. Sorry to say so.

Let random failures and connection loses. Have processed about 20 million records already.

Only issue is getting head around the promise based setup. Although there's a callback API available. This of course has nothing to do with squaremo :)

[barshow]

Ill self promote a little bit and recommend https://github.com/dropbox/amqp-coffee we use it very heavily, like billions of messages a day. Started with node-amqp, and improved reconnecting, and a lots of other things.

[squaremo]

The main things people seem to miss, coming from node-amqp to amqplib, are callbacks (rather than promises) and some variety of auto-recovery. I relented on the former and added a callback-oriented API not long ago.

Auto-recovery I have always thought of as a misfeature, but people have reported that it works OK for what they're doing. And I've seen AMQP clients in other languages with auto-recovery working in practice, so I am more accustomed to the idea now, even if I still think it's very tricky (maybe impossible) to get right.

Of course, moving across, there is a bit of porting work to do, since amqplib is not that similar to node-amqp's API (which I believe to be mistaken).

[simonmorley]

@squaremo I agree with your point about auto-recovery. Our Rabbit cluster doesn't sit within our core network and hides behind haproxy. The failures we see are numerous (network fails) and no library we've used handles them all.

Initially I thought this was the responsibility of the library but in hindsight realise the developer needs to be fully aware of why a failure might occur.

We use your library and don't bother with failures, just let the process die and restart with forever. The microseconds of downtime don't have any affect on us.

However, within the ruby-amqp library we also use, we do use the built-in recovery feature but have had to wrap some extra error handling to make it work (primarily in the event RabbitMQ is down when it restarts).

With node-amqp, even though there was auto-recovery, it didn't work for us. We ended up altering things slightly as per #345

With your library, the promise based architecture was a challenge for us but overall, we've had far more success and our random connection drops (and therefore missing data) have vanished completely. The port was worth it :)

[zeusdeux]

@squaremo what's your reasoning behind thinking of reconnection as a misfeature, if I may ask?

[bakkerthehacker]

Shameless plug for my own amqp library: https://github.com/bakkerthehacker/bramqp

I have thought about writing a higher level wrapper around bramqp that implements a similar api to node-amqp. However I don't think this would be possible without going through the library and depricating a handful of the functions.

In the meantime, the only higher level solutions seem to be https://github.com/squaremo/amqp.node and https://github.com/dropbox/amqp-coffee Unfortunatley maintaining amqp-node seems to be a lost cause at this point. :(

[zeusdeux]

I have personally shifted our whole codebase from here to @squaremo's amqp.node and the only thing I miss is auto reconnect. This does seem dead, yes.