[rabbitmq-discuss] Connect/Disconnect Queue

Randall Richard randall at trellisapp.com
Thu Nov 14 15:04:43 GMT 2013


FWIW, thought it's worth referring to this somewhat related thread from
last year:
https://groups.google.com/forum/#!msg/rabbitmq-discuss/XDgTCiPGcfM/dREUwL0ZxD8J

Not sure it still works as before, but I did subscribe to the messages sent
to in amq.rabbitmq.log and you can get some string based info on connect /
disconnects.

-Randall



On Wed, Nov 13, 2013 at 10:29 AM, Tim Watson <tim at rabbitmq.com> wrote:

> Hi,
>
> On 13 Nov 2013, at 12:34, Lars Ellebo wrote:
> > Is there a way to configure a Queue that will generate a message every
> time
> > a user Connects or Disconnects ?
> >
> > The message shall contain at least the UserId and whether the Used did
> > Connect or Disconnect.
> >
>
> Apart from the fact that this would violate a number of security
> principles, it's possible but not without writing a custom plugin. I have
> considered writing a plugin that listens for management events describing
> "schema changes" (i.e., CRUD operations on users, vhosts, queues,
> exchanges, etc) that publishes this information to an exchange and binds a
> queue to it. The user (installing the plugin) would need to ensure this is
> "locked down" to prevent security holes from appearing as a result. I
> hadn't considered adding connect+disconnect events though, because (a)
> these could be extremely frequent and could harm performance, plus (b) I
> can't quite see why such information would be useful. One of the primary
> reasons for using messaging oriented middleware is to de-couple producers
> from consumers, whereas providing a stream of schema-oriented information
> seems quite useful if you're working with dynamically changing topologies.
> Perhaps from a statistics monitoring point of view
>  the connect/disconnect information is useful, but you can get that by
> polling the management HTTP API already, and I'm not sure whether adding a
> queue based feed would be the best way to present an alternative interface
> to such information. Simon may well have more/better points to add on this.
>
> Cheers,
> Tim
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131114/88c84c0c/attachment.htm>


More information about the rabbitmq-discuss mailing list