qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CLIVE <cl...@ckjltd.co.uk>
Subject Re: Message API - Real world usage issue
Date Tue, 18 Feb 2014 19:20:18 GMT

Sorry about the previous z, slip of the old fingers...

As you say, my API is wrong and I will need to think again. Just started 
playing with AMQP 1.0, once I have a better understanding of this and 
how a Client API might encapsulate both implementations, I will try again.

Thanks for all the help, your AMQP 1.0 user notes were particularly 
useful in getting started with the new version.



On 17/02/2014 19:12, Fraser Adams wrote:
> 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.
> Cheers,
> Frase

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message