<div dir="ltr">FWIW, thought it's worth referring to this somewhat related thread from last year:�<a href="https://groups.google.com/forum/#!msg/rabbitmq-discuss/XDgTCiPGcfM/dREUwL0ZxD8J">https://groups.google.com/forum/#!msg/rabbitmq-discuss/XDgTCiPGcfM/dREUwL0ZxD8J</a><div>
<br></div><div>Not sure it still works as before, but I did subscribe to the messages sent to in�<span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">amq.rabbitmq.log and you can get some string based info on connect / disconnects.</span></div>
<div><br></div><div>-Randall<br><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 10:29 AM, Tim Watson <span dir="ltr"><<a href="mailto:tim@rabbitmq.com" target="_blank">tim@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On 13 Nov 2013, at 12:34, Lars Ellebo wrote:<br>
> Is there a way to configure a Queue that will generate a message every time<br>
> a user Connects or Disconnects ?<br>
><br>
> The message shall contain at least the UserId and whether the Used did<br>
> Connect or Disconnect.<br>
><br>
<br>
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<br>
�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.<br>
<br>
Cheers,<br>
Tim<br>
<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</blockquote></div><br></div>