[rabbitmq-discuss] binding key

[Chris]

Hello Sagar,

AMQP defines a HEADER exchange that allows you to match based on headers.
 It's briefly discussed in the "AMQP Explained" document:
http://www.rabbitmq.com/tutorials/amqp-concepts.html.  I think I've heard
that this exchange doesn't perform as efficiently as some of the others,
though...

In addition to the standard AMQP exchanges, there are also some custom
exchanges for other routing strategies (like consistent hash exchange:
http://hg.rabbitmq.com/rabbitmq-consistent-hash-exchange/file/rabbitmq_v3_1_5/README.md,
or
a few at the bottom of this page: http://www.rabbitmq.com/devtools.html).

And if you're feeling brave, you can also create your own custom exchange...

-Chris

On Monday, October 7, 2013, PATAR, SAGAR wrote:

> Apart from binding keys .. can we use some other header property or
> attribute of the message for routing ??
>
> -----Original Message-----
> From: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:
> rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of PATAR, SAGAR
> Sent: Monday, October 07, 2013 10:12 AM
> To: Discussions about RabbitMQ
> Subject: Re: [rabbitmq-discuss] mirrored queue cluster
>
> *** Security Advisory: This Message Originated Outside of AT&T ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
>
> Thanks Michael ..
> When you say NO changes in framework ...I am little confused..
>
>  Let's say a new consumer is introduced  ..
>
> 1)The consumer can simply subscribe BUT there is NO way the dynamic queue
> is mirrored and also if the consumer has a downtime then the messages
> published during the downtime will be lost as the dynamic queue will be
> deleted .. Even if there is a feature where the dynamic queue is not
> deleted when the connection fails .. Can we mirror that queue and also how
> can we make sure when the client reconnects will it be using the same queue
> or will create a NEW queue...
>
> 2)If we need to mirror the queue the new consumer is going to consume from
> then we might have to do some confutation changes ..right??
>
> " Note that I was explaining things in AMQP 0-9-1 terms, and now you've
> revealed that your
> requirements are framed in JMS terms, which are not exactly the same." ..
> Can we use Rabbit to achieve the JMS based requirements ??
>
> -----Original Message-----
> From: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:
> rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Michael Klishin
> Sent: Monday, October 07, 2013 9:41 AM
> To: Discussions about RabbitMQ
> Subject: Re: [rabbitmq-discuss] mirrored queue cluster
>
>
> On oct 5, 2013, at 7:48 p.m., "PATAR, SAGAR" <sp345s at att.com> wrote:
>
> > The requirement we have is a simple JMS topic with failover and
> persistency..
> > Where multiple client subscribe for the messages and when a new client
> is introduced NO changes in framework as  the Topic is already configured
> for failover and persistence ..the new client will just make a connection
> and start consuming ..
> >
> > With RabbitMQ my understanding is we need to configure a new queue and
> mirror it and then ask the new client to consume the message ...??
> >
> > Pl. check slide 3 and  4 in the attachment ... For new client do we need
> to configure a new mirrored queue ... All the queues should get all the
> messages from the exchange ...
>
> Unfortunately, I'm not familiar with how vFabric Rabbit's JMS client maps
> RabbitMQ protocol
> to JMS.
>
> Perhaps one of my colleagues has an answer for this?
>
> MK
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131007/d79e80fd/attachment.htm>