[rabbitmq-discuss] A new exchange type
bill at soudan.net
Wed Jan 28 17:25:32 GMT 2009
I had sent a message a month or two ago about this as well, but then I was sidetracked... on the main website, the last-value-cache is described as an external service, but I agree it makes more sense (and I believe I asked about) to implement it as a new exchange type.
Unfortunately I just haven't had the time to work an the implementation yet, but I agree this would be extremely useful and that an exchange type (or new flag?) seems the natural place to implement this in AMQP.
The only thing that is unresolved in my mind is the corner case when a queue binds to a topic but there has been NO value published for the topic. What to do here? In an asynchronous system, you may need to be able to distinguish between "no-current-value" and "the-current-value-is-just-taking-a-long-time-to-arrive". Prior to AMQP, I was using some custom middleware and I'd implemented a 'no-current-value' message for this condition. Some options, but I haven't explored them thoroughly yet:
1) Deliver a 'no-current-value' message using the regular publish mechanism. Easy to implement, but perhaps not the best given there are no other cases that I'm currently aware where AMQP servers generate content.
2) Implement a new AMQP message that indicates this condition and deliver it after the queue.bind if there is no current cached value. Better than #1 but requires cooperation from the AMQP guys?
3) If there is a AMQP queue.bind_ok message (I think?), then deliver the current value prior to the bind_ok message. This implies if there is no data delivered before the bind_ok, that there is no current value. Possibly forbidden by the specification, however, but requires no special content message, no new AMQP implementation, and probably fits most naturally in the implementation (receive bind request, send the most recent value if any, reply bind_ok). My favorite option if the spec allows it.
----- Original Message -----
From: "Alister Morton" <Alister.Morton at tradition.com>
To: "rabbitmq-discuss at lists.rabbitmq.com" <rabbitmq-discuss at lists.rabbitmq.com>
Sent: Wednesday, January 28, 2009 6:05:21 AM (GMT-0500) America/New_York
Subject: [rabbitmq-discuss] A new exchange type
We have a use pattern in mind that I think would require development of a new exchange type, and a couple of conversations with Alexis would seem to reinforce this view that, currently, the functionality we have in mind doesn't exist in rabbitmq.
What we'd like to do is have an exchange type which acted like a regular topic exchange, where messages are "routed" into queues based on the topic, but in addition kept a copy of the last message sent to the exchange for each topic. So the behaviour of the exchange would be slightly different to how it is at the moment. Currently, if you create a purely topic based exchange, and publish a message to it, then some time alter attach a queue to that subject, no message is delivered until the next message is published to that topic. With the new exchange the newly connected queue would immediately receive a message that was a copy of the last message published, however long ago it was. Clearly, the timestamp on the message is important, but this architecture could, I think, be very useful. One use would be as a replacement for the proprietary "market data feed" type servers many institutions use to share internal data records. Although there is clearly a distinction between a "r
ecord" and a "message" it would be very simple, and for many purposes perfectly adequate, to build a simple internal feed system around a RabbitMQ message broker with this new, additional exchange type.
Anyone else see a use for it? We're currently weighing up the pros and cons of having such an exchange developed for rabbit, or continuing to use our own, internally developed but proprietary message broker, which /does/ implement last message persistence in this way.
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 othe
r 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 Autho
rity. VAT No: GB 365 4639 27 except TFS-ICAP GB 766 0854 05.
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss