Implement a "Will" (as in "last will and testament") message

[smurfix]

MQTT has a nice feature which AMQP lacks: upon connecting, you can send a message that the server will retain and publish when the client disconnects unexpectedly.

It'd be nice if RabbitMQ had an extension which provides this feature.

Rationale: I need to keep track of which client is connected to the bus. Broadcasting keepalive messages doesn't scale.

[michaelklishin]

It already does.

[michaelklishin]

Using most messaging protocols for presence is not something I'd recommend regardless.

[smurfix]

Sorry, apparently I didn't write clearly. I do know about RabbitMQ's MQTT front-end/plug-in, but what I meant was to provide for this using the "native" AMQP protocol in some way.

Switching to MQTT doesn't work for my application, as I need too many other features which AMQP provides.

[michaelklishin]

This feature doesn't really fit the AMQP 0-9-1 protocol. We would consider it if there's enough user interest.

[meverett]

I also really like this feature from the MQTT protocol and would love a more native version of the same in RabbitMQ (ideally in the AMQP spec as I believe it's a very useful feature). This is especially helpful in the world of IoT devices. Often times devices only implement one main messaging protocol like AMQP or MQTT and it speeds up/simplifies development to be able to have this functionality built in, without having to implement a secondary communication layer and additional keep alive system (like say over HTTP or MQTT), which increases firmware size and complexity.

There are plenty of use cases for wanting to know when a client or device has become disconnected/unavailable ungracefully; this is especially important in the world of sensor telemetry. Often times unexpected client disconnections are events that require reactionary/recovery workflows.

The advantages of having such a feature built in include:

• Less overall sockets or communication layers to manage in clients who's main protocol is already AMQP (otherwise you'd have to implement your own in a semi-redundant, alternative communication protocol just to add in connection state events that can be broadcast).
• The server already manages connection state, so it is in a great position to be able to handle broadcasting events in the case of ungraceful client disconnects.
• Since the server is already a message bus with queuing and pub/sub it is possible to easily broadcast and handle disconnection events without having to implement a redundant pattern elsewhere.
• In the MQTT version you can specify the topic, retain/persisted flag, QoS, and payload to be broadcast upon ungraceful disconnect, which means there are many creative and powerful ways to route the disconnection message to which allows you to handle sophisticated broadcast scenarios and workflows.

Having worked with both MQTT and AMQP I can say that there are very few things from the MQTT protocol that I prefer over AMQP, but the Last Will and Testament feature is definitely one of them.

Having the RabbitMQ MQTT plugin (which it sounds like implements the LWT feature) is a decent work around. But it is rather cumbersome to have to include and support an additional client library just to add in this functionality which is a pretty common use cases for telemetry.

[michaelklishin]

@meverett the only way to amend AMQP 0-9-1 spec is via extensions. This is not a discussion forum, please post your ideas to rabbitmq-users.

[meverett]

@michaelklishin You said it's something that would be considered if there was enough interest so I was replying, expressing my interest in context to the feature request. I apologize, but you didn't specify a desired destination to express interest and I've never seen any other repository where doing so in the issue's comment thread itself was actively discouraged. I thought that was the point? Nothing in CONTRIBUTING.md, CODE_OF_CONDUCT.md, or http://www.rabbitmq.com/github.html indicated otherwise. Many projects gauge interest on issues through such a process. I'm sure the reasons exist, I've just yet to run into a project that doesn't utilize issue discussions in such a manner. Maybe consider making that desire more visible in the README or something similar with high visibility. I would have been happy to direct my comment/interest to the correct location had I known what that was and had I known it would have been discouraged in this context. I won't reply further, but I wanted to offer that feedback since I know others will share my experience of it being pretty customary to express contextual interest and thoughts in the comments of an issue, especially when finding it as one of the top results of a search as to whether or not the feature exists.

[michaelklishin]

@meverett it's not discouraged, I simply pointed out that this team does not use GitHub issues for discussions, questions, and so on. Specifically this means that

• it is unlikely that you will get a detailed response here from our team
• if other users turn this into a free form discussion, the issue will be locked

Interest can be expressed in many ways that do not assume a response. Those looking to convince our team or suggest a specific protocol extension idea can post to rabbitmq-users. If/when we are convinced and have a reasonably formed idea, we'd be happy to update this issue description or even file a new one.

Other "repositories" are free to use GitHub issues however they please.