Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of fraser.adams@blueyonder.co.uk
 designates 81.103.221.48 as permitted sender)
Message-ID: <50E6B8D2.4000002@blueyonder.co.uk>
Date: Fri, 04 Jan 2013 11:11:14 +0000
From: Fraser Adams <fraser.adams@blueyonder.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: QMF dead to new requests after invoking some create calls
References: <1780103952.23591302.1357240686946.JavaMail.root@redhat.com>
In-Reply-To: <1780103952.23591302.1357240686946.JavaMail.root@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 03/01/13 19:18, Ken Giusti wrote:
> Hi Fraser,
>
> I think the fix for this bug is to prevent the headers exchange from allowing multiple bindings with the same keys.
>
> In that case, when entering the following commands:
>
> qpid-config bind amq.match test f1 all k1=v1
> qpid-config bind amq.match test f1 any k1=v1
>
> the second qpid-config command would fail (binding already in use).

Yes I agree I think that the second command *should* fail as the 
<exchangeName>/<queueName>[/<bindingKey>] combination is the same for 
both and it's that combination of names that are used internally. At 
least for 0.12 duplicates are accepted without QMF sending an exception 
(unlike for adding queues or exchanges where an exception "object 
already exists <name>" gets reported by by the invokeMethod response).

>   I think that - for headers exchanges - the binding key isn't really used beyond identifying the binding (so you can eventually delete it).
I personally encourage the use of a binding key for the headers 
exchange, you are correct that it is optional and it looks as though if 
you add a single binding without a key you can actually add it and 
delete it, but having an explicit key helps add clarity IMHO - I 
generally use descriptive keys that relate to what the binding is trying 
to achieve.


> So you could get the same behavior doing:
>
> qpid-config bind amq.match test f1 all k1=v1
> qpid-config bind amq.match test f2 any k1=v1
>
> instead. At least that is what I remember - it's been awhile.  What do you think?
Yes with different keys it's possible to add an any and an all match, 
though the former then becomes redundant.

If you then do

qpid-config bind amq.match test f3 all k1=v1

so basically add a duplicate binding but with a different key it doesn't 
get added (silently). I think that not adding it is probably the right 
thing to do, but I don't like it silently failing I think an exception 
should be sent back.


There's definitely plenty of inconsistency though, I've just tried 
adding bindings to an xml exchange, but if I add two bindings with keys 
f1 and f2 with the same xquery they get added - this is largely 
equivalent to adding headers bindings with the same k/v properties, 
which as said above doesn't get added, so that seems inconsistent.

What's even weirder is if I try to add another xml binding with key f1 
but with a different xquery that binding doesn't get added (silently) 
but I don't get "error Detected two management objects with the same 
identifier:" from the broker, which suggests that for the xml exchange 
some sort of test is being done on the overall key (unlike the case for 
the headers exchange) but an exception isn't being reported back.
>> Hopefully my Qpid GUI will be in a releasable state in the next couple
>> of days, I'm currently going through some final bugs & snags and a
>> little bit of work to get it looking nice on mobile browsers.
> Very cool!  Have you tried running it against 0.20 release candidate qpidd?   Should work fine, but it's always nice to get extra exposure before we cut the release.
>
> -K
>
It's looking pretty good now, it's quite flashy with iOS style animated 
page transitions. It's basically a single page web-app using AJAX to 
update the state. What I've done is write a Java Qpid REST API bridging 
to my QMF2 implementation then on the JavaScript side I've written a QMF 
API wrapper to the REST API, so my core JavaScript GUI code actually 
talks the QMF2 API.

I did it that way 'cause it provides much cleaner abstraction. At the 
moment the bridge is pure REST/HTTP but I might extend that in the 
future to use WebSockets, I've not done that yet as a) I've not got much 
Web Socket experience and b) it has poorer cross-browser support. At the 
moment by GUI runs on everything from IE6 up to modern mobile browsers. 
The main bit of styling I've yet to do is to do a bit of "real-estate 
adjustment" for small displays like iPhone - it's currently got a 
sidebar a la iPad which needs to be hidden on smaller devices. Nearly 
there though :-)

I've not tried it with anything later than 0.12 yet. Unfortunately every 
time I've upgraded qpid version I've needed to fight the makefile. I 
noticed that Gordon Sim has incorporated a patch I did for the makefile 
into 0.20 so hopefully that pain will go away shortly. I'll give it a 
whirl with 0.20 before I release.

I *hope* nothing breaks. It *should* be OK unless anyone has messed 
around with the QMF2 logic??? I recall between 0.8 and 0.10 there was a 
change to QMF Events where they started to get sent as AMQP lists from 
0.10 unfortunately amqp lists don't map terribly well to JMS and I ended 
up using some of Gordon's code that used the low-level AMQP decodes. So 
unless anyone has been messing around with mappings from AMQP list to 
JMS it should just work.

I'm off to write some more code now :-)

Frase


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