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
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.
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.
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: [email protected]
For additional commands, e-mail: [email protected]
