qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: The future of Qpid Management.
Date Sat, 01 Mar 2014 16:40:30 GMT
More comments inline below with some snippage.

On 28/02/14 19:51, Rob Godfrey wrote:
> On 28 February 2014 19:36, Fraser Adams <fraser.adams@blueyonder.co.uk>wrote:
>
>> Funnily enough my "mental model" of AMQP 0.10 in an AMQP 1.0 context has
>> tended to be as above with bindings as "internal links".
>>
>> Though it's probably not as clear-cut as that. For sure if a producer is
>> sending to an exchange (as an addressable node) and a consumer is receiving
>> from a queue (as an addressable node) and we've established some bindings
>> administratively then creating said bindings is pretty close to
>> establishing an internal link, However if one has a consumer receiving from
>> an exchange as an addressable node it gets more interesting in that case
>> although we have a queue created (in physical terms) that queue is really
>> an artefact of the subscription and is (I think) actually a source terminus
>> associated to the exchange node and one or more links.
>>
>> That's all quite "exciting" because the same physical things on the broker
>> are semantically a little different depending on how things were
>> established, which messes with my head a bit :-D don't know whether it's
>> possible (or whether you'd want to) distinguish between the two different
>> scenarios in a Management Model??
>>
>>
>>
> So to me, if you allow subscriptions to an exchange then you should present
> to the management user the same view that the application is getting (i.e.
> the fact that a queue object has been created to provide buffering is an
> implementation detail).
Hmm "kind of", so I'd be content that this was a different type of queue 
than a queue node, but the information is still pretty useful.

We've discussed some time ago that my core use case is perhaps a little 
different than ones that your customers tend to use but mine involves 
real-time very high rate producers, and consumers that need to scale out 
and select messages based on their properties, so my subscriptions tend to:
1) Be "shared" subscriptions - so I can have multiple physical consumer 
hosts receiving from a given subscription queue (i.e. they may be viewed 
as the same logical consumer scaled out across several physical 
instances over multiple hosts).
2) The subscription queues don't (generally) need to be durable, though 
they are in a couple of cases.
3) I absolutely need ring/circular queues because my producers are real 
time and I can't slow down time if a consumer happens to fail :-)
4) I can't just simply throw away messages entirely if a consumer fails 
either - so I have "topic like" behaviour, but also a need to give a 
little leeway in case the consumer failure is transient (I tend to use 
queues around 2GB) if the consumer is down and stays down messages get 
overwritten because of the circular queue, but if the consumer comes 
back before that happens it can catch up. That's another reason for the 
shared subscription queues 'cause consumers can scale out to recover 
from a backlog.

All of that stuff is possible in AMQP 0.10 exchange/binding/queue model 
and is also possible in AMQP 1.0 (in qpidd at anyrate) using shared 
subscription queues (e.g. with node: {capabilities: [shared]}) and using 
Gordon's "topic" pseudo-node as a mechanism to configure subscription 
queues created by topic-like nodes (this is how I create my ring queues) 
e.g.

qpid-config add topic topic --argument exchange=amq.match \
--argument qpid.max_size=2000000000 --argument qpid.policy_type=ring


At the moment when I do all of that stuff in qpidd it *looks* like I end 
up with an exchange node, a queue node and bindings between them, though 
in practice as I say I think that the queue is semantically not *really* 
a queue node and might be better as something else (perhaps as I said 
earlier a source terminus associated with the exchange).

However from my perspective recording it the way that it's currently 
done is actually pretty useful because I like to be able to see the 
subscription queues and I also like to be able to determine what's 
connecting to them (and/or be able to find any subscription queues 
associated with a connection).


>   I think ultimately in the Java Broker I would like
> to allow consumers to link to things that look a lot like exchanges,
> however I think the behaviour might be slightly different.  To me an
> exchange is an instance of a class of nodes which passes messages from an
> incoming link to an outgoing link without ever taking responsibility for
> the message (or providing any buffering/storage).
Hmmm I think this is a little bit of a grey area. You are probably right 
to say what you are saying above, but without associated storage the 
pub/sub model breaks down a little because you generally want to be 
decoupling publishers from subscribers and without queues it's hard to 
decouple.

To my mind what you are describing above feels more like the sort of 
behaviour of a router than a broker.

That said, I sort of agree with what you are saying from a philosophical 
level, that's one of the reasons that I quite like Gordon's "topic" 
pseudo-node concept, so in that case you're describing something that 
looks a lot like an exchange, but allows subscription queues to have a 
particular configuration.


>   A queue is an instance
> of the class of nodes that does take responsibility for a message (and - as
> it happens - also provides storage).  A link may or may not provide
> buffering / storage (links between containers will always have to provide
> buffering...
Is it the link or is it the terminus? I'm clearly not as much of an AMQP 
1.0 expert as you are, but I thought that a link multiplicity was 0..1 
at each end (from the perspective of the link) so for the concept of 
shared subscriptions to be possible the storage is *really* in the 
source terminus rather than the link if you are considering subscription 
queues.

> internal links may or may not provide buffering - currently
> the Java Broker models message flows across bindings as a synchronous
> operation) but never itself takes responsibilitiy.  So, to my mind I feel
> that an exchange with subscriptions should either insist that all messages
> sent to it are sent unreliably (pre-settled), or it should only settle when
> consumers have taken the message and taken responsibility themselves.  This
> is somewhat different from the 0-x exchange behaviour where the broker
> takes responsibility for the message (because it actually places the
> message in one or more queues).
>
As I say above I'd kind of agree with this from a purist/philosophical 
perspective, but again as I say about this feels somewhat more 
router-like behaviour than broker like.

At the moment (in qpidd at least) the default behaviour when subscribing 
to an exchange is for a temporary queue to get created, I guess I'd be 
reasonably agnostic about a move to a model like you are suggesting 
above *as long as* I've still got the ability to execute my core use 
case above - if we call things that allow such behaviour topics rather 
than exchanges then I really don't mind, but I really *do mind* if I 
can't execute my core use case!!


 From my perspective I think Gordon has done a brilliant job providing 
AMQP 1.0 mappings and mechanisms for this sort of complex use case and I 
for one want to publicly thank him!! I've not had a chance yet to see if 
similar mechanisms exist in the Java Broker, though I'd expect some 
differences even if roughly equivalent /mechanisms/ exist.

It's surprisingly complex, though perhaps I shouldn't be surprised given 
how little AMQP 1.0 actually mandates.

> Yes - I think we'd need to start out simple... all queues have names...
> right? and then see what aspects we think are common, which should be
> factored and where we currently have different ways of doing things trying
> to decide whether there is a common abstraction which we can use to
> describe across both instances (and in Dispatch and Messenger too).  In
> general I feel there is probably more in common with stuff that both
> brokers are capable of than there is different...
So the general philosophy of what you are saying I don't dispute, the 
point that I was making was that there is currently some baggage around 
even this simple stuff in both QMF and the Java Broker model - at a 
trivial level whose name do we pick? Are you willing to change property 
names? Are the QMF guys? It's not *technically* hard for sure, but it 
does need a fairly grown-up attitude and a shared desire, so probably 
needs good leadership on the part of the Java and C++ camps to get that 
sort of alignment.

>   However there will also
> be large amounts of functionality that is specific to one broker or the
> other... and that is fine.  Where the other side has an interest we should
> discuss the naming / semantics... and maybe aspire to implement at some
> later date... But as long as we keep things in bite-sizd chunks and not try
> to say that every queue has to implement all these bazillion features, then
> I don't think it will necessarily be as hard as you might think.
>
As above I largely agree that it's not *technically* too hard, it's more 
that the community has to buy in and engage with the spirit of trying to 
align as much as is sensible and perhaps to accept that some much-loved 
property names will get changed for the common good.


> So one of my issues with QMF is that schema and mechanism weren't as
> cleanly separated as I'd like.  The ability to perform the CRUD operations
> appears to be a property of Broker objects rather than something generic...
Perhaps, but if you look at QMF Broker Management Objects in another way 
they are actually pretty darned close to the behaviour of and AMQP 1.0 
Management Node albeit with a few Manageable Entity properties thrown in.

     <method name="create" desc="Create an object of the specified type">
       <arg name="type" dir="I" type="sstr" desc="The type of object to 
create"/>
       <arg name="name" dir="I" type="sstr" desc="The name of the object 
to create"/>
       <arg name="properties" dir="I" type="map" desc="Type specific 
object properties"/>
       <arg name="strict" dir="I" type="bool" desc="If specified, treat 
unrecognised object properties as an error"/>
     </method>

     <method name="delete" desc="Delete an object of the specified type">
       <arg name="type" dir="I" type="sstr" desc="The type of object to 
delete"/>
       <arg name="name" dir="I" type="sstr" desc="The name of the object 
to delete"/>
       <arg name="options" dir="I" type="map" desc="Type specific object 
options for deletion"/>
     </method>

     <method name="query" desc="Query the current state of an object.">
       <arg name="type" dir="I" type="sstr" desc="The type of object to 
query."/>
       <arg name="name" dir="I" type="sstr" desc="The name of the object 
to query"/>
       <arg name="results" dir="O" type="map"  desc="A snapshot of the 
object's state."/>
     </method>

So you do say:

create(name, type, properties)

Which is pretty darned like section 5.2 where you talk to $management 
and pass
application-properties:
name->newQueue
operation->CREATE
type->org.example.queue

application-data:
A map of properties pretty similar to the properties passed in a QMF 
create.....



As I said in my previous reply I'm not suggesting that QMF is in any way 
perfect, but it certainly has mechanisms for events and query 
subscriptions (and I like getObjects.....) sure sorting out some of the 
more untidy request/response semantics and moving away from the 
amq.default.direct/amq.default.topic to being able to address the 
Management Node directly all seem reasonable, but I still think that an 
evolution from that rather than trying a ground up approach would have 
made things easier - a lot of the conversations around AMQP 1.0 
Management have seemed to be around things that already work pretty well 
in QMF.

Clearly we are where we are and the most important thing now is to make 
sure that AMQP 1.0 Management evolves, grows and achieves wide adoption 
and I for one am certainly keen to see that happen and be supportive of 
it, but that shouldn't stop me voicing the odd bit of frustration or 
getting on my soap-box every now and again :-D


> I completely agree that number of mallocs makes sense for some
> implementations... but it certainly doesn't make sense for all.  What I
> want to see is that we have something that says "here's how you do common
> operations agaisnt any type of object - including some sort of event
> stuff", along side: "here are the common attributes, methods defined for
> these common entity types... though your vendor will likely have all sort
> of other goodies on top".
That all sounds fair enough.

>   One thing to remember is that for AMQP 1.0,
> we're not only thinking about the sort of role that QMF played for Qpid...
> but also the fact that in AMQP 1.0 there is no longer a way of creating
> queues programmatically... So the basic case that we wanted to cover
> quickly is a way to programmatically dynamically create (non temporary)
> queues and such.
So I get that, though FWIW:
1) "in AMQP 1.0 there is no longer a way of creating queues 
programmatically " does really bug me. I'd love to know the reason for 
this - is the answer "politics"? Do some vendors not have this ability 
hence it couldn't be specified or they wouldn't sign up? Being able to 
create a named node with specified properties seems a pretty reasonable 
use case so why AMQP 1.0 doesn't allow it is utterly beyond me I'm afraid.
2) I'm not convinced that AMQP 1.0 Management (or QMF) are the most 
enjoyable way to programmatically do this. It's still quite an annoying 
faff to do a request/response and populate all the Map body etc. *just 
to create a queue*. I'd accept that AMQP 1.0 Management makes it a 
little less of a faff than QMF2, but it's only just a little less of a faff.
3) If I'm honest I think that I prefer Gordon's QueuePolicy/TopicPolicy 
where you administratively create what amounts to a factory that gets 
triggered by a link attach (there's clearly nothing to stop you creating 
queues via AMQP 1.0 Management too but "forcing" people to faff around 
with request/reponse/Maps is nobody's idea of fun IMHO)
qpid-config add TopicPolicy header-exchange-* --argument 
exchange-type=headers --argument auto-delete=false --argument 
alternate-exchange=amq.match --argument qpid.ive=1 --argument 
qpid.msg_sequence=1
./drain --connection-options {protocol:amqp1.0} -b localhost -f 
"header-exchange-test"

>    The wider management use cases perhaps haven't been as
> completely explored yet as they could be... And certainly having those who
> can contribute directly, and those who can't be members of OASIS contribute
> their thoughts to the Technical Committee through the TC comments mailing
> list would be of great value!
>
I guess that's reasonable, though between the Java Broker UI and the QMF 
UI we've probably got a good subset of the broker use cases covered. I 
suspect that the more interesting unexplored use cases are around the 
ability to use AMQP 1.0 Management more generally to manage other 
containers (such as clients) - though TBH that's a similar use case that 
the QMF Agent mechanism addressed.

At the risk of getting dragged into a protocol versus API debate I think 
that there's some argument for having a management API so that massive 
amounts of wheel reinvention doesn't end up happening every time someone 
wants to enable AMQP 1.0 Management capabilities to their container.

The argument for an API probably isn't too strong if it's only about 
managing the brokers, but it's stronger if we want to make it easy to 
add useful management to arbitrary containers.


> So, my view is that the JMX API will stay as it is (forever more).  For the
> REST API I think we would try to migrate people as seamlessly as possible
> when attribute names changed or the semantics of operations did so...
> however we are very deliberately not at a 1.0 release because I think there
> are likely to be breakages in the APIs until we get stuff nailed down as a
> community, and hopefully in the wider AMQP world.
>
Yeah, all that sounds entirely reasonable. It feels quite an exciting 
time to be part of the Qpid (and AMQP) community. I feel a little 
happier now that I'm starting to get my head around AMQP 1.0 a bit more, 
though it'll be nice when the AMQP 1.0 stuff starts to stabilise - in 
particular it'll be good when the JMS client reaches "mission-critical 
ready".


One other thing that I keep forgetting to mention; in QMF2 Agents 
broadcast heartbeat messages periodically to a topic so clients can 
identify if Agents have gone away. I guess that this is perhaps more 
useful in QMF2 where Agents aren't *necessarily* co-located with the 
Broker, but it has got me thinking. In AMQP 1.0 Management I guess that 
the $management node is likely to be pretty coupled to the Container's 
lifecycle such that a client could probably infer that the $management 
node is gone based on interception of a connection failure (e.g. via 
something like a Connection Exception Listener) but a couple of use 
cases fall out of that sort of scope:
1) What about Management nodes other than $management? It's possible 
that the Container and $management might be available, but some other 
Management node a user is interested in might possibly die 
asynchronously for whatever reason (a simple use case might be one 
client DEREGISTERing a Management Node that another client happens to be 
using).
2) What about Message-oriented (as opposed to Connection-oriented) APIs 
such as Messenger, with those the fact of Connection closing wouldn't 
necessarily register until the next time a request was made.

Clearly a Management client could figure this out by some sort of 
polling - and that might be better than needing a topic to broadcast a 
heartbeat (though it doesn't scale as well if there are lots of clients) 
but if polling is the expected way to accomplish this then I'd say that 
the Management Specification needs to specify a standard Management node 
operation to achieve this (perhaps STATUS ?). For someone designing a 
decoupled client (say a WebApp) being able to determine the status of 
Management nodes and provide feedback to the user is pretty useful.

Cheers,
Frase




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