You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by chenta <ch...@gmail.com> on 2009/02/05 10:07:42 UTC
Replication of message
Hi,
I am new to Qpid and I have a simple question.
Is it possible that there are more the one consumers subscribe to the same
queue but all receive the same message like broadcasting? or I have to use
pub-sub/fanout to do that? However, if I use fanout to do the "broadcast",
it means that every consumer have to own a unique queue, am I correct?
Thanks,
Chenta
--
View this message in context: http://n2.nabble.com/Replication-of-message-tp2273886p2273886.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Replication of message
Posted by Carl Trieloff <cc...@redhat.com>.
chenta lee wrote:
> Thanks for your reply.
> What do you mean by non-destructive consumer? Is it a consumer with a
> non-deleted queue?
> By the way, is there other methods to remove the non-auto-deleted
> queue? Could it be done by the client?
not quite, a non-destructive consumer, is a queue browser, or in AMQP
0-10, the messages are acquired but
not dequeued, so they are left on the queue for another consumer to see.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Replication of message
Posted by chenta lee <ch...@gmail.com>.
Thanks for your reply.
What do you mean by non-destructive consumer? Is it a consumer with a
non-deleted queue?
By the way, is there other methods to remove the non-auto-deleted queue?
Could it be done by the client?
Thanks,
Chenta
On Thu, Feb 5, 2009 at 8:53 PM, Carl Trieloff <cc...@redhat.com> wrote:
> chenta wrote:
>
>> Hi,
>> I am new to Qpid and I have a simple question.
>> Is it possible that there are more the one consumers subscribe to the same
>> queue but all receive the same message like broadcasting? or I have to use
>> pub-sub/fanout to do that? However, if I use fanout to do the "broadcast",
>> it means that every consumer have to own a unique queue, am I correct?
>>
>> Thanks,
>> Chenta
>>
>>
>
> this can be done but using non-destructive consumers. The messages can then
> be discarded via a
> variety of mechnism. Using the C++ broker the following options exist.
> - Using TTL to age and destroy the messages.
> - Size limiting the queue for discarding old messages via a size policy
> like ring.
> - etc
> On the Java broker,
> TTL would be the way to go.
>
> And ten of cause you can create an autodelete queue for each consumer. not
> really any cost
> in doing this also, allow destructive consumers.
>
> Carl.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
Re: Replication of message
Posted by Carl Trieloff <cc...@redhat.com>.
> Is there any way to administratively set things up so that the policies
> regarding which exchange to subscribe to and what broker to connect to etc
> can be controlled by administrators easily? WHere can i find a reference of
> the commands / conf files for qpid brokers and clients?
>
just do --help on any of the commands.
the list of commands are
qpid-cluster
qpid-printevents
qpid-route
qpid-config
qpid-queue-stats
qpid-tool
--help also works on the broker, qpidd --help and options get added to
list as modules are loaded. I see we don't
a page on this -- will create one
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Replication of message
Posted by Carl Trieloff <cc...@redhat.com>.
yes, there are a set of tools in the python package. use qpid-config
http://qpid.apache.org/mgmtc.html
Carl.
GS.Chandra N wrote:
> >Sure, let talk about terminology. In AMQP there is an exchange and a
> queue. ........
>
> Thanks Carl.
>
> This is cool. What you just described is really what i want - a pub
> sub model.
>
> Is there any way to administratively set things up so that the
> policies regarding which exchange to subscribe to and what broker to
> connect to etc can be controlled by administrators easily? WHere can i
> find a reference of the commands / conf files for qpid brokers and
> clients?
>
> Thanks
> Gs
>
> On Thu, Feb 5, 2009 at 11:36 PM, Carl Trieloff <cctrieloff@redhat.com
> <ma...@redhat.com>> wrote:
>
> GS.Chandra N wrote:
>
> Hi,
>
>
>
> this can be done but using non-destructive consumers.
>
>
>
> Cant subscriptions be created between multiple private queues
> -> public
> queue that contain the messages everyone is interested in to
> create the same
> effect? Or would that be too much of a load ?
>
> I'm yet to start with the actual client api but the 1.0 draft
> design left me
> with this impression.
>
> On the same topic, how do message subscription get handled in
> a federated
> environment.
>
> Would clients connected anywhere in the federated tree
> receieve messages
> irrespect of where they originate ?
> How do brokers in the federated tree come to know about
> subscriptions
> created elsewhere in the heirarchy? Is this supported?
>
>
>
> Sure, let talk about terminology. In AMQP there is an exchange and
> a queue. This of the exchange
> as the router, which can be named for example. So to do the above
> you would declare a fanout exchange
> and then publish to that. every consumer would create a tmp queue
> and bind it to the exchange and would
> get all the messages sent to that named destination.
>
> Carl.
>
>
>
Re: Replication of message
Posted by "GS.Chandra N" <gs...@gmail.com>.
>Sure, let talk about terminology. In AMQP there is an exchange and a queue.
........
Thanks Carl.
This is cool. What you just described is really what i want - a pub sub
model.
Is there any way to administratively set things up so that the policies
regarding which exchange to subscribe to and what broker to connect to etc
can be controlled by administrators easily? WHere can i find a reference of
the commands / conf files for qpid brokers and clients?
Thanks
Gs
On Thu, Feb 5, 2009 at 11:36 PM, Carl Trieloff <cc...@redhat.com>wrote:
> GS.Chandra N wrote:
>
>> Hi,
>>
>>
>>
>>> this can be done but using non-destructive consumers.
>>>
>>>
>>
>> Cant subscriptions be created between multiple private queues -> public
>> queue that contain the messages everyone is interested in to create the
>> same
>> effect? Or would that be too much of a load ?
>>
>> I'm yet to start with the actual client api but the 1.0 draft design left
>> me
>> with this impression.
>>
>> On the same topic, how do message subscription get handled in a federated
>> environment.
>>
>> Would clients connected anywhere in the federated tree receieve messages
>> irrespect of where they originate ?
>> How do brokers in the federated tree come to know about subscriptions
>> created elsewhere in the heirarchy? Is this supported?
>>
>
>
> Sure, let talk about terminology. In AMQP there is an exchange and a queue.
> This of the exchange
> as the router, which can be named for example. So to do the above you would
> declare a fanout exchange
> and then publish to that. every consumer would create a tmp queue and bind
> it to the exchange and would
> get all the messages sent to that named destination.
>
> Carl.
>
>
>
Re: Replication of message
Posted by Carl Trieloff <cc...@redhat.com>.
GS.Chandra N wrote:
>> Sure, let talk about terminology. In AMQP there is an exchange and a queue
>>
>
> Carl, how come the amqp1.0 draft and the transport.pdf does not talk about
> the concept of exchanges. I just did a search again and saw nothing
> mentioned. Where can i get moer information.
very good question..
In AMQP 1.0, what we have as an exchange and a queue are being placed
into a single concept. This makes
this like JMS topics a bit easier to deal with in the broker. In AMQP
1.0 you can think of an existing exchange
as a AMQP 1.0 queue with 0 length and a queue in AMQP 1.0 as a 0-10
queue with a server side selector attched.
So the mapping to 1.0 from a model stand point will be quite natural.
One of the features that have today in the C++ broker,
the IVE (Initial Value Exchange) which is basically a AMQP 1.0 queue
construct with a queue depth policy of 1.
hope that helps
Carl.
Re: Replication of message
Posted by "GS.Chandra N" <gs...@gmail.com>.
>Sure, let talk about terminology. In AMQP there is an exchange and a queue
Carl, how come the amqp1.0 draft and the transport.pdf does not talk about
the concept of exchanges. I just did a search again and saw nothing
mentioned. Where can i get moer information.
Thanks
gs
On Thu, Feb 5, 2009 at 11:36 PM, Carl Trieloff <cc...@redhat.com>wrote:
> GS.Chandra N wrote:
>
>> Hi,
>>
>>
>>
>>> this can be done but using non-destructive consumers.
>>>
>>>
>>
>> Cant subscriptions be created between multiple private queues -> public
>> queue that contain the messages everyone is interested in to create the
>> same
>> effect? Or would that be too much of a load ?
>>
>> I'm yet to start with the actual client api but the 1.0 draft design left
>> me
>> with this impression.
>>
>> On the same topic, how do message subscription get handled in a federated
>> environment.
>>
>> Would clients connected anywhere in the federated tree receieve messages
>> irrespect of where they originate ?
>> How do brokers in the federated tree come to know about subscriptions
>> created elsewhere in the heirarchy? Is this supported?
>>
>
>
> Sure, let talk about terminology. In AMQP there is an exchange and a queue.
> This of the exchange
> as the router, which can be named for example. So to do the above you would
> declare a fanout exchange
> and then publish to that. every consumer would create a tmp queue and bind
> it to the exchange and would
> get all the messages sent to that named destination.
>
> Carl.
>
>
>
Re: Replication of message
Posted by Carl Trieloff <cc...@redhat.com>.
GS.Chandra N wrote:
> Hi,
>
>
>> this can be done but using non-destructive consumers.
>>
>
> Cant subscriptions be created between multiple private queues -> public
> queue that contain the messages everyone is interested in to create the same
> effect? Or would that be too much of a load ?
>
> I'm yet to start with the actual client api but the 1.0 draft design left me
> with this impression.
>
> On the same topic, how do message subscription get handled in a federated
> environment.
>
> Would clients connected anywhere in the federated tree receieve messages
> irrespect of where they originate ?
> How do brokers in the federated tree come to know about subscriptions
> created elsewhere in the heirarchy? Is this supported?
Sure, let talk about terminology. In AMQP there is an exchange and a
queue. This of the exchange
as the router, which can be named for example. So to do the above you
would declare a fanout exchange
and then publish to that. every consumer would create a tmp queue and
bind it to the exchange and would
get all the messages sent to that named destination.
Carl.
Re: Replication of message
Posted by "GS.Chandra N" <gs...@gmail.com>.
Hi,
>this can be done but using non-destructive consumers.
Cant subscriptions be created between multiple private queues -> public
queue that contain the messages everyone is interested in to create the same
effect? Or would that be too much of a load ?
I'm yet to start with the actual client api but the 1.0 draft design left me
with this impression.
On the same topic, how do message subscription get handled in a federated
environment.
Would clients connected anywhere in the federated tree receieve messages
irrespect of where they originate ?
How do brokers in the federated tree come to know about subscriptions
created elsewhere in the heirarchy? Is this supported?
Thanks
gs
ps : Sorry if i might have asked too many questions if there is document i
can refer on that would do too.
On Thu, Feb 5, 2009 at 6:23 PM, Carl Trieloff <cc...@redhat.com> wrote:
> chenta wrote:
>
>> Hi,
>> I am new to Qpid and I have a simple question.
>> Is it possible that there are more the one consumers subscribe to the same
>> queue but all receive the same message like broadcasting? or I have to use
>> pub-sub/fanout to do that? However, if I use fanout to do the "broadcast",
>> it means that every consumer have to own a unique queue, am I correct?
>>
>> Thanks,
>> Chenta
>>
>>
>
> this can be done but using non-destructive consumers. The messages can then
> be discarded via a
> variety of mechnism. Using the C++ broker the following options exist.
> - Using TTL to age and destroy the messages.
> - Size limiting the queue for discarding old messages via a size policy
> like ring.
> - etc
> On the Java broker,
> TTL would be the way to go.
>
> And ten of cause you can create an autodelete queue for each consumer. not
> really any cost
> in doing this also, allow destructive consumers.
>
> Carl.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
Re: Replication of message
Posted by Carl Trieloff <cc...@redhat.com>.
chenta wrote:
> Hi,
> I am new to Qpid and I have a simple question.
> Is it possible that there are more the one consumers subscribe to the same
> queue but all receive the same message like broadcasting? or I have to use
> pub-sub/fanout to do that? However, if I use fanout to do the "broadcast",
> it means that every consumer have to own a unique queue, am I correct?
>
> Thanks,
> Chenta
>
this can be done but using non-destructive consumers. The messages can
then be discarded via a
variety of mechnism. Using the C++ broker the following options exist.
- Using TTL to age and destroy the messages.
- Size limiting the queue for discarding old messages via a size policy
like ring.
- etc
On the Java broker,
TTL would be the way to go.
And ten of cause you can create an autodelete queue for each consumer.
not really any cost
in doing this also, allow destructive consumers.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org