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:52:04 GMT
On 10 March 2013 17:41, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
> 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.
>

OK... found the code...

        _persistentSizeHighThreshold =
storeConfiguration.getLong(MessageStoreConstants.OVERFULL_SIZE_PROPERTY,
-1l);
        _persistentSizeLowThreshold =
storeConfiguration.getLong(MessageStoreConstants.UNDERFULL_SIZE_PROPERTY,
_persistentSizeHighThreshold);

The store implementations monitor their own size against these
settings and generate events.  The Broker listens for the events and
implements system wide flow control until the store gets below the
lower limit.

I'll try to respond to your more philosophical questions later this
evening... My flight is boarding now :-)

-- Rob

>>
>> 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