[rabbitmq-discuss] A new exchange type

[Alister Morton]

> Alternatively (and please note that this is purely a
> theoretical speculation on my part), is the broker itself the
> best place to run this extended functionality?
That's a very valid question.

> For example, if core broker could expose AMQP events via AMQP
> (i.e., broker itself will be sending messages to a certain
> protected exchange every time a queue is created, or consumer
> connects, or consumer disconnects, etc) plus have its runtime
> state obtainable via AMQP (again - send a request message to
> a certain exchange, get response), then I could hopefully
> implement last-value-cache scenario totally in user-space.
> (This could also help with monitoring, btw).

In order that last value caching can work, you'd need to be able to ask the broker to notify you (a publisher) whenever a queue was connected to an exchange that you'd flagged as needing last value caching, in order that the last value can be pushed again. But this last value must only be pushed to the newly connecting queue, so it would have to have some kind of flags attached to it to indicate that it was a refresh and was not to be passed to queues that had already seen it. While this is possible, I think it could add as much complexity as adding a new exchange type.

What does everyone else think?

al

(Apologies for the big sig, BTW - company mail server adds it :( )

The information herein may have been obtained from various sources. Any opinion expressed may be that of the sender only, is subject to change without notice and should be independently evaluated. Nothing herein constitutes investment advice or an offer, or solicitation of an offer, to buy or sell any financial product. Any data consists of purely indicative prices and should not be relied upon to revalue any commercial positions held by any recipient. Tradition makes no warranty that the data represent or indicates prices at which transactions may be or have been made by any Tradition Group company. To the maximum extent of the law, Tradition accepts no responsibility for, and cannot and does not warrant the integrity, accuracy, quality, completeness, merchantability or suitability for a particular purpose or requirement of the information or data, even if arising out of the negligence of Tradition or otherwise. Tradition accepts no liability for any direct, indirect or other consequential loss arising out of any use of the information contained in this document or any omission from it. This communication is directed at Eligible Counterparties and Professional Clients as defined by the FSA. It is not for distribution to nor should it be relied upon by Private Clients. It is not intended for distribution to, or use by any person or entity in any jurisdiction or country where such distribution or use would be contrary to any applicable law or regulation. Please note that, for business or compliance reasons, we may monitor and read emails sent or received using our servers or equipment. Tradition (UK) Ltd (937647; FSA 139200), Tradition Financial Services Ltd (1046064; FSA 147543), TFS Derivatives Ltd (4051930; FSA 197244), Tradition London Clearing Ltd (3633863; FSA 190632) and TFS-ICAP Ltd (4025995; FSA 206018) registered in England at Beaufort House, 15 St Botolph Street, London EC3A 7QX; authorised and regulated by the Financial Services Authority. VAT No: GB 365 4639 27 except TFS-ICAP GB 766 0854 05.