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: Message API - Real world usage issue
Date Mon, 17 Feb 2014 19:12:01 GMT
On 17/02/14 18:13, CLIVE wrote:
> Fraze,
It's with an "s" :-)

> Thanks for taking a further look at this. I have not come across the 
> selector option before. In fact I tried it today at work on a 0.20 
> version, but got an exception due to this option not being a valid 
> name. Currently building 0.26 and will give it another go tomorrow.
> Just one thought, as the selector is part of the link section, will 
> this still work if the receivers are all in the same process, using a 
> single session. I had hoped to try this today but ran out of time 
> waiting for the 0.26 version to build.
To be honest I've not tried this I've only just started messing with 
this stuff myself over the last few weeks (you might have seen my post 
"A write up of some AMQP 1.0 Experiments") and I've mainly been using 
spout and drain for simplicity so I didn't have to write any code :-)

As it happens using Selectors with a queue node wasn't something I'd 
tried at all until I saw your post, so I figured I might as well have a 
play and was quite pleased that at face value it seems to be doing 
something fairly close to your use case :-)

To answer your question though I'm no AMQP 1.0 expert but in the AMQP 
1.0 specification section 2.1.2 figure 2.9 illustrates a class diagram 
of communication endpoints and that shows multiplicities as follows:

| Link        | Message Transport
+-------------+ (Node to Node)
| name        |
| source      |
| target      |
| timeout     |
     /|\ 0..n
     \|/ 0..1
| Session    | Frame Transport
+------------+ (Container to Container)
| name       |
     /|\ 0..n
     \|/ 1..1
| Connection | Frame Transport
+------------+ (Container to Container)
| principal  |

In other words the Session to Link multiplicity is 0..n which *suggests* 
that it should "still work if the receivers are all in the same process, 
using a single session". Worst case scenario would be you might need 
different sessions, but I suspect that it'll probably be fine. I think 
that it's just a case of calling createReceiver with the appropriate 
address - I think that the receiver in AMQP 1.0 terms is a terminus, 
which *does* have an association with the Link unlike your previous 
thought process where you assumed that the bindings had an association 
with the receiver (which they don't).

Oh one thing that I've not actually tried is what happens if something 
is on your single queue *ahead* of things you care about - so what 
happens if you have bob/bill/tim selectors and you send a message with 
the subject "freddy" ahead of the message with the subject "tim" (if you 
see what I mean).

I can't try it out at the moment because I currently can't compile off 
trunk 'cause something is broken :-(

You've hopefully also seen my posts that relate to the "subject" - it 
works fine in AMQP 0.10 using "qpid.subject" but in AMQP 1.0 it's part 
of the immutable properties and has a specific accessor - it should be 
fairly easy to add support if people think it's useful though.

> Will be looking at AMQP 1.0 over the next few weeks.
> Anyway thanks for all the advice and help so far.
> Clive
No worries, hope it has been useful - helps me learn more stuff too :-)

FWIW though I'm *still* not convinced that producers delivering 
everything to the same queue is the best idea if you've got a mixture of 
fast and slow producers writing to the same queue you run a risk of the 
fast producers "bullying" the messages of the slower one, I'm not sure 
what you have against queues. FWIW even if you configure a queue with 
say 2GB capacity that capacity is only used if the queue is actually 
full so 100*1MB queues or 1*100MB queue you still need sufficient 
capacity to cope with producer burstiness or consumers dying.

In your earlier mail you said:

So at run time you have no way of knowing what address strings are going 
to be passed to you.

The User application then makes the following calls on your API

   Messaging.registerUserCallback( "queue1; {create: receiver, node: 
{x-declare:{auto-delete:true}, x-bindings: [{exchange: 'amq.topic', 
queue: 'queue1', key: 'bill'}]}}" ,usrCallback1);
   Messaging.registerUserCallback( "queue2; {create: receiver, node: 
{x-declare:{auto-delete:true}, x-bindings: [{exchange: 'amq.topic', 
queue: 'queue1', key: 'ben'}]}}" ,usrCallback2);

The User application might not make a call with an address string that 
references the same queue, but as a good API designer, you need to be 
able to handle it.

I'd argue that in this case you've not *really* got your own API, you've 
just added a convenient abstraction around qpid::messaging, in which 
case you've not actually really abstracted users away from having to 
supply Address Strings that are semantically correct.

As explained in previous responses people supplying the address strings 
would *still* need to be aware that the x-bindings associated a queue 
with an exchange and were actually unrelated to the receiver.

To make it a true API that abstracts that stuff you do need to have 
application code.

Given that you've discovered that using selectors has a different syntax 
and indeed with AMQP 1.0 the way you're using topic matches changes too 
(do read the post I mentioned above) you just might want to provide a 
true API to abstract this where your registerUserCallback() takes a 
queue name a key and a callback - just a thought.


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