qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: QMF dead to new requests after invoking some create calls
Date Thu, 03 Jan 2013 19:18:06 GMT
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).  I think that - for headers
exchanges - the binding key isn't really used beyond identifying the binding (so you can eventually
delete it).  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?


> 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

----- Original Message -----
> Thanks for the update Ken.
> 
> "but since the problem is rarely hit" clearly we're not adding enough
> bindings :-) I'll soon change that :-D
> 
> 
> I'll probably add some defensive code in my GUI. It's a little bit of
> a
> faff to do but I've already got a cache of Binding, Queue and
> Exchange
> QMF objects, so when I go to add a new binding I can look through the
> Binding objects for ones that match my binding key then dereference
> the
> queueRef/exchangeRef IDs to lookup queue/exchange names associated
> with
> said binding to check if my <exchangeName>/<queueName>/<bindingName>
> key
> is unique.
> 
> It's not *quite* infallable as the cache only gets updated every 10
> seconds, but it's *probably* good enough. I might look at forcing a
> cache refresh just before the test, but that's getting a lot more
> complex as I'm actually getting my QMF objects back from an AJAX call
> to
> a REST implementation of the QMF2 API :-)
> 
> 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.
> 
> Regards,
> Frase
> 
> On 03/01/13 17:32, Ken Giusti wrote:
> >
> > This appears to be a bug in the way the amq.match (Headers
> > Exchange) is implemented.
> >
> > The exchange+queue+binding-key need to be unique - QMF uses that
> > tuple as the mgmt object index.   However, it seems the Headers
> > Exchange also considers the header configuration (k1=v1, etc) when
> > it checks for existing bindings.  In the above case, since the
> > header values are different, the exchange creates two bindings
> > even though the exchange+queue+binding key are the same.  That's a
> > bug.
> >
> > Gordon hit this bug awhile ago while using federation -
> >  https://issues.apache.org/jira/browse/QPID-3356.
> >
> > The other problem - the hang - is probably related: QMF's handling
> > of duplicate object errors has been improved quite a bit since
> > 0.12, but since the problem is rarely hit there are probably still
> > bugs in it.
> >
> >
> > -K
> >
> > -
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

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


Mime
View raw message