<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1257">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.0.6619.12">
<TITLE>RE: [rabbitmq-discuss] A new exchange type</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Great idea Alister, it could be useful indeed.<BR>
<BR>
Just my quick thoughts about functionality that may be needed:<BR>
1) When declaring exchange, ability to specify the count of messages to hold (not only just last one)<BR>
2) ability to specify expiration date or time span and hold messages to that date<BR>
<BR>
What do you think?<BR>
<BR>
Currently we are using custom implementation of second the case. When a user starts listening to newly declared query, he also asks “service” for the last messages that haven’t timeout.<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: rabbitmq-discuss-bounces@lists.rabbitmq.com on behalf of Alister Morton<BR>
Sent: Tr 2009.01.28 13:05<BR>
To: 'rabbitmq-discuss@lists.rabbitmq.com'<BR>
Cc: <BR>
Subject: [rabbitmq-discuss] A new exchange type<BR>
<BR>
Maybe.<BR>
<BR>
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.<BR>
<BR>
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 "record" 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.<BR>
<BR>
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.<BR>
<BR>
<BR>
<BR>
al.<BR>
<BR>
<BR>
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.<BR>
<BR>
_______________________________________________<BR>
rabbitmq-discuss mailing list<BR>
rabbitmq-discuss@lists.rabbitmq.com<BR>
<A HREF="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</A><BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>