qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: Java broker queue questions....
Date Sun, 10 Mar 2013 17:05:26 GMT
What Rob said, plus a few expansions in-line


On 10 March 2013 16: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.
> 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
>

First up, yes the queues differ significantly.

The java broker uses flow control in cases where you wish to limit the
amount of data on a queue, but currently has no functionality that the the
C++ broker might to e.g overwrite/discard messages when things hit a
certian size, or make enqueues fail immediatley when queues hit a certain
size, etc.

You will find that the different management interfaces and internal
implementation objects in the Java broker may currently have different
names for the same thing in some cases. This is because we are in the
middle of transitioning the broker to a new config model and decided to
rethink the names while we were at it (e.g, whoever called the soft
alerting threshholds 'maxFoo' for example wasnt thinking very hard about
things that day), but wanted to mainting compatibility with e.g the old JMX
management interface because all our users existing tooling is still using
that.


> 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.
>
> As Rob mentioned, flow control vs alrts, and as above regarding the
different names for the same conceptual value.


> 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.
>
>
No, we dont journal per-queue, and instead have per-virtual host message
stores. Currently the only attribute of a queue that affects persistence in
any way is 'durable', though we have spoken of adding options to e.g.
override the regular decision to record the enqueues of persistent messages.


> I'm sure I'll find more discrepancies but I wouldn't mind answers to these
> for starters.
>
>
>
> 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<users-unsubscribe@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

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