qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Java broker queue questions....
Date Sun, 10 Mar 2013 16:41:04 GMT
On 10 March 2013 17:29, Fraser Adams <fraser.adams@blueyonder.co.uk> wrote:
> Having done exchanges to death :-) .........
>
> There appear to be *plenty* of differences between queues on the C++ broker
> and on the Java broker.
>
> 1) Is there an equivalent of ring policy in the Java broker? From what I can
> see there's a few queue types standard (I guess that's the equivalent of
> reject policy), priority, lvq and sorted - but no ring.

Nope... again, there's code somewhere attached to a JIRA I believe,
but there's nothing checked in

> 2) Setting the capacity seems different I had a queue with an AddressString
> "testqueue; {create: receiver, node: {x-declare: {arguments:
> {'qpid.policy_type': ring, 'qpid.max_size': 500000000}}, x-bindings:
> [{exchange: 'amq.match', queue: 'testqueue', key: 'data1', arguments:
> {x-match: all, data-service: amqp-delivery, item-owner: fadams}}]}}";
> the binding gets set fine but the policy and max_size get ignored. Now I
> know that x-declare is "implementation specific", but it would be nice if
> Qpid was consistent between the two brokers :-)
>
> am I correct in thinking that for the Java broker the way to set the
> capacity is using "x-qpid-capacity"? What seems slightly odd though is that
> in the management object this is referred to as
> QUEUE_FLOW_CONTROL_SIZE_BYTES

You wouldn't expect us to be consistent event within the same codebase
would you? :-)

> 3) Similar to 2 the C++ broker uses qpid.max_count to specify the max size
> in messages, am I correct in thinking that the equivalent in the Java broker
> is "x-qpid-maximum-message-count" which is
> ALERT_THRESHOLD_QUEUE_DEPTH_MESSAGES. That said I'm really confused 'cause
> I've noticed ALERT_THRESHOLD_QUEUE_DEPTH_BYTES which causes
> _queue.setMaximumQueueDepth, what's the difference between that and
> _queue.setCapacity.
>

So Capacity and Resume Capacity are the points at which flow control
is enforced - this means that if a publisher enqueues a message onto a
queue which goes above capacity then the broker flow controls that
session to prevent all outbound messages until the queue drops below
the resume capacity.

The MaximumQueueDepth is used for alerting... if you go above that
then you start getting alerts.

There's no correlation required between these two settings (nor must
one be set if the other is).

> 4) Is there an equivalent to file-size/file-count which is used in the C++
> broker to do journal config? I'm guessing not but I can't see any
> persistence config attributes on the Queue ConfiguredObject on the Java
> broker.
>

Nope - nothing like that.  There is a way of setting broker wide flow
control when the total broker file size gets above a given level.  I
can't remember the details off hand... I know it uses events generated
from the store.  At an airport at the moment and don't have the code
handy to look it up.

>
> I'm sure I'll find more discrepancies but I wouldn't mind answers to these
> for starters.
>
>

No problem,

Rob

>
> As a philosophical question, given all of the quirky little differences an
> interesting question might be "what exactly is Qpid"? there's two AMQP
> brokers, but both quite different, supporting different queue and exchange
> types and even with different declaration options, I guess they evolved
> separately so perhaps it's not surprising but it's *really* confusing :-)
>
> I've mentioned this casually to Gordon Sim, but I think that I'm more
> adamant about this than ever now. I *really* think that some effort needs to
> be put into "branding" Qpid. Part of that is about providing maximum
> cohesion and interoperability between the brokers and the client libraries.
>
> Particularly now that Proton appears to be being used in say ActiveMQ for
> AMQP 1.0 support I think it becomes all the more important to have the "big
> set of features" like you have on shrink wrapped software so users know what
> Qpid is and so when someone is tasked with selecting between a big list of
> Messaging platforms it really jumps out why Qpid is the right choice!!
>
>
> Cheers,
> Frase
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message