On 10/03/13 09:51, Rob Godfrey wrote:
On 10 March 2013 09:42, Fraser Adams <[email protected]> wrote:
I'd really like to understand more about how this is currently working in
AMQP 1.0/Proton do you have some example Addresses that are being used - I'm
particularly interested in how an existing AddressString containing a
headers exchange and bindings to that might work.
So, what the Java Broker does under the covers is actually to create a
temporary subscription queue.
That's interesting, that sounds fairly analogous to the federation in
the C++ broker for things like dynamic exchange route and static
exchange routes where *logically* exchanges are being linked together,
but at the implementation level a temporary queue gets created.
I guess from your previous response about what AMQP 1.0 does (and does
not :-)) specify an awful lot is potentially at the level of
"implementation detail". That feels like a rich seam of confusion that
we're likely to be mining for quite some time I suspect :-D
One could actually implement
subscriptions to exchanges such that published messages are not
acknowledged until they have been flowed to all recipients... but that
would have been a bigger piece of work.
That's interesting. My gut feeling is that it might be pretty dangerous.
There's already a lot of scope for memory issues. I've been bitten in
the past by quirks related to prefetch, so for example messages get sent
to the prefetch queue on say slow consumers and end up building up on
the broker because it can't remove the references until the client has
acknowledged. When one actually thinks about what's going on it all
makes sense, but it took me an age to get under the skin of this sort of
behaviour and I wonder if some of these higher level abstractions and
implementation details could leave people scratching their heads. I had
enough problems thinking "my messages are hitting a queue with ring
policy why on earth is the broker memory growing - and growing". If it
was only *logically* hitting an exchange I suspect that it would
*really* have melted my mind (and I've got a tenuous enough grip on
sanity as it is :->)
Ultimately I want to just add "topic" nodes rather than abusing
exchanges for this purpose (I had a 10 line patch that did this that
is probably still sitting around somewhere). The primary
implementation difference is that messages at the head of a "topic"
get silently dropped if there are no subscriptions that have not yet
passed that message.
Are you suggesting here that your "topic" node implements an internal
queue ("messages at the head of a "topic" get silently dropped" is
suggesting that to me).
I have some issues with that and again it's analogous to federation.
Ultimately I've been forced into using queue routes for federation due
to the limitations of the "internal queues" that have been implemented
for the "exchange routes" ultimately having non-configurable internal
queues is a pain in the butt - I'd really have liked to be able to
specify the size and policy of the internal queue.
I'm concerned that some of these thoughts around AMQP 1.0 might a)
become inconsistent between the C++ and Java brokers and b) cause
problems like I suggest above where the may not be as configurable as
users need.
Perhaps, but it's probably a good topic to start, the AMQP 1.0 work has been
quietly going on in dev land and I think this is probably a good time to
start sharing the love a bit on the user list.
+1. We definitely need to talk more about AMQP 1.0 on this list as
well as better explaining what things are AMQP 1.0 and what things are
"Qpid".
Cool I'm glad that you agree. It's definitely an interesting time but
there may be some pain ahead for users as things move forward and good
communication (and documentation) seems to me to be the best way to
mitigate this.
BTW you asked previously "I don't suppose you work for a firm that is
already an OASIS member, do you?" unfortunately not. As it happens all
of my Qpid work is done in my own time at weekends
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
