Hi Tim,<div><br></div><div>I've added some comments inline. I'm very happy to help you with requirements here so if a call would help let me know and I'll set it up.</div><div><br></div><div>Do you have a timeline for this feature?</div><div><br></div><div>Regards</div><div><br></div><div>John<br><br>On Wednesday, 3 July 2013 21:24:26 UTC+1, hyperthunk wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">We've got an open bug to provide a 'message groups' feature like this and are hoping to get it ready for a feature release ASAP.
<br>
<br>Just out of interest, for your use-case, how would you expect failover to work.</blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Do you want all future messages delivered to another random consumer? <font color="#ff0000">(Yes)</font></blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">What about un-acked messages that were already delivered - we plan on redelivering these <font color="#ff0000">(Agree)</font> - and how do you plan on explicitly terminating a group? <font color="#ff0000">(This is not a requirement. Groups should only be terminated by a connection closing either explicitly or due to failure)</font></blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Would a special message (or header) given by the producer suit that purpose? <font color="#ff0000">(If people want this functionality I would suggest this is the best way. You might also consider giving the consumer the ability to terminate a message group but we don't have a specific use case for this. It might be something for future releases.)</font></blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">What about consumers that don't disconnect but indicate they'd like to stop processing that group of messages? <font color="#ff0000">(I referred to this above. I'd suggest you add this to a future release as it really is not a must have).</font> Do you have consumers that want to recieve more than one group in parallel? <font color="#ff0000">(Absolutely)</font> And what about producers that go away - do you close the group when they disconnect or keep it open indefinitely, or use a timeout? <font color="#ff0000">(I would keep it open indefinitely because multiple producers may be contributing messages to a single group. You have some challenges around clean up here though. It could be reasonable to say that when all messages in a group have been processed that the group closes after a timeout. When subsequent messages arrive the group is recreated.)</font><br>
<br>None of those things are very clear to me from the activemq docs, so hearing from a real world user would be nice! :)
<br>
<br>Cheers,
<br>Tim
<br>
<br>On 3 Jul 2013, at 11:57, John Turner <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="lnSIGu9JEkIJ">john....@thoughtforge.net</a>> wrote:
<br>
<br>> Hi All,
<br>>
<br>> I'm very familiar with JMS and have used the GroupID extension to provide processing affinity to a single consumer. For further information on how this works see this ActiveMQ documentation: <a href="http://activemq.apache.org/message-groups.html" target="_blank">http://activemq.apache.org/<wbr>message-groups.html</a>
<br>>
<br>> This solves the following requirement:
<br>>
<br>> * Messages are distributed to a queue with a GroupID header.
<br>> * The broker guarantees that messages with a specific GroupID (say '1234') will only be processed by a single consumer.
<br>> * If the consumer fails (i.e. the connection is broken or closed), the broker will allow another consumer to process messages with that GroupID
<br>>
<br>> Using RabbitMQ and the Consistent Hashing Plugin does not not appear to solve the problem because if we are using static (durable) queues, the consumer failover mechanism needs to be implemented outside the server. Does anyone have any insight into this problem they could share?
<br>>
<br>> An alternative would be to extend the queue to ensure apply the same consistent hashing mechanism to the actual queue rather than the broker. Does anyone know if it si possible to extend the queue implementation?
<br>> ______________________________<wbr>_________________
<br>> rabbitmq-discuss mailing list
<br>> <a href="javascript:" target="_blank" gdf-obfuscated-mailto="lnSIGu9JEkIJ">rabbitmq...@lists.<wbr>rabbitmq.com</a>
<br>> <a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<wbr>cgi-bin/mailman/listinfo/<wbr>rabbitmq-discuss</a>
<br></blockquote></div>