qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: limit policy on bound temporary queues
Date Tue, 18 Dec 2012 12:30:32 GMT
Hi Lance,

The address can be used in most of the new APIs - including C++ and Java.
In C++ (the qpid.messaging API, not the deprecated qpid.client) you can
pass this address as a string when creating the receiver using
session.createReceiver(...). In Java, it is a bit more complicated, because
you have to create the receiver based on JNDI destination which is created
with the address. But the address it self is the same for all clients.

C++ example:
std::string address= "queue_1; {create: receiver, assert: never," +
            "node: { type: queue, x-declare: { auto-delete: true,
exclusive: false, arguments: {'qpid.policy_type': ring, 'qpid.max_count':
1000, " +
            "'qpid.max_size': 1000000}}, x-bindings: [{exchange:
'exchange_1', queue: 'queue_1', key: 'routing_key_1'}]}}";
receiver = session.createReceiver(address);

Regards
Jakub


On Tue, Dec 18, 2012 at 1:12 PM, Lance D. <lanced@gmail.com> wrote:

> Thanks Jakub.  Correct me if I'm wrong, but those commands to create the
> queue are the python commands, correct?  What would that look like in c++?
>
> And I really like the ACL list idea.  That will make it much easier to
> enforce proper client behavior.
>
> -Lance
>
> On Tue, Dec 18, 2012 at 3:01 AM, Jakub Scholz <jakub@scholz.cz> wrote:
>
> > Hi Lance,
> >
> > From the client you can use address similar to this to create and
> temporary
> > ring type queue:
> >
> > queue_1;
> > {
> >     create: receiver,
> >     assert: never,
> >     node:
> >     {
> >         type: queue,
> >         x-declare:
> >         {
> >             auto-delete: true,
> >             exclusive: false,
> >             arguments:
> >             {
> >                 'qpid.policy_type': ring,
> >                 'qpid.max_count': 1000,
> >                 'qpid.max_size': 1000000
> >             }
> >         },
> >         x-bindings:
> >         [
> >             {
> >                 exchange: 'exchange_1',
> >                 queue: 'queue_1',
> >                 key: 'routing_key_1'
> >             }
> >         ]
> >     }
> > }
> >
> > This creates the auto-delete ring type queue named queue_1 with capacity
> > for 1000 messages or 1000000 bytes and binds it to the exchange named
> > exchange_1 suign the routing key "routing_key_1". I assume for fanout
> > exchange, you do not need the routing key.
> >
> > If you want, you can also use ACLs to allow the clients to create only
> ring
> > type queues:
> >
> > acl allow user1@QPID create  queue name=queue_*  maxqueuecount=1000
> >  maxqueuesize=1024000  policytype=ring durable=false autodelete=true
> >
> > This rule will make the broker reject all attempts to create a queue
> which
> > doesn't fulfill all the specified options.
> >
> > Regards
> > Jakub
> >
> > On Tue, Dec 18, 2012 at 4:09 AM, Lance D. <lanced@gmail.com> wrote:
> >
> > > Hello,
> > >
> > > I'm trying to figure out a problem and I'm hoping to find the right way
> > to
> > > make this happen.
> > >
> > > I've got a data producer that publishes to an fanout exchange.  My
> system
> > > requires that under no circumstances can the producer get throttled
> > because
> > > even if 1 user can't keep up, the other consumers need the data as soon
> > as
> > > possible.  My thought is that if I just force all of the consumers to
> > > connect with a 'ring' limit policy, then I should be okay because slow
> > > consumers will just drop data on the floor.  So I'd like to be able to
> > make
> > > that the default policy.
> > >
> > > That said, I'm fairly certain that isn't possible, so I'd at least like
> > to
> > > setup my clients with the correct settings.  I've read through the
> > > documentation, but I can't seem to figure out how to register to
> receive
> > > from an exchange, using a temporary (implicit) queue.
> > >
> > > Thanks in advance for the help.
> > > -Lance
> > >
> >
>
>
>
> --
> //=========================\\
> || 505.610.7896 (cell)                       ||
> || 703.367.2069 (work)                     ||
> \\=========================//
> --------------------
> ....................
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message