| Summary: | Addressing documentation is lacking clarity | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | William Henry <whenry> |
| Component: | Messaging_Programming_Reference | Assignee: | Joshua Wulf <jwulf> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Cheryn Tan <chetan> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 2.0 | CC: | chetan, dryan, jskeoch, jwulf, lcarlon, rlandman |
| Target Milestone: | 2.2 | Keywords: | Documentation |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-09-20 03:13:11 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Note: By injecting a 'print message' statement in the _method() method of /usr/lib/python2.7/site-packages/qpidtoollibs/broker.py, I've cribbed the following:
qpid-config add exchange topic test-topic2
Message(subject='broker', reply_to='qmf.default.topic/direct.5df5d602-7cb6-42c7-9ac2-37489ec0f758;{node:{type:topic}, link:{x-declare:{auto-delete:True,exclusive:True}}}', correlation_id='1', properties={'qmf.opcode': '_method_request', 'x-amqp-0-10.app-id': 'qmf2', 'method': 'request'}, content={'_object_id': {'_object_name': 'org.apache.qpid.broker:broker:amqp-broker'}, '_method_name': 'create', '_arguments': {'strict': True, 'type': 'exchange', 'name': u'test-topic2', 'properties': {'exchange-type': u'topic'}}})
qpid-config add exchange fanout test-fanout
Message(subject='broker', reply_to='qmf.default.topic/direct.6da5bfc3-44fb-4441-b834-6c5897b9606a;{node:{type:topic}, link:{x-declare:{auto-delete:True,exclusive:True}}}', correlation_id='1', properties={'qmf.opcode': '_method_request', 'x-amqp-0-10.app-id': 'qmf2', 'method': 'request'}, content={'_object_id': {'_object_name': 'org.apache.qpid.broker:broker:amqp-broker'}, '_method_name': 'create', '_arguments': {'strict': True, 'type': 'exchange', 'name': u'test-fanout', 'properties': {'exchange-type': u'fanout'}}})
qpid-config add queue test-queue
Message(subject='broker', reply_to='qmf.default.topic/direct.35aec21d-1193-4ad1-9475-ae1f86be8887;{node:{type:topic}, link:{x-declare:{auto-delete:True,exclusive:True}}}', correlation_id='1', properties={'qmf.opcode': '_method_request', 'x-amqp-0-10.app-id': 'qmf2', 'method': 'request'}, content={'_object_id': {'_object_name': 'org.apache.qpid.broker:broker:amqp-broker'}, '_method_name': 'create', '_arguments': {'strict': True, 'type': 'queue', 'name': u'test-queue', 'properties': {}}})
(I think i'll keep this version of qpid-config, it's quite useful...)
So I think that the fully recommended way to create exchanges is via QMF method messages.
Apart from that, there are some anomalies with addressing and existing objects that may be bugs:
qpid-config add queue doppleganger
qpid-config add exchange topic doppleganger
will create a queue and an exchange, both with the name 'doppleganger'. Attempts to interact with them through addressing will resolve to the queue only, regardless of the order of creation (testable by using assert)
On the other hand:
spout 'uniqueindividual; {create:always, node:{type:topic}}'
spout 'uniqueindividual; {create:always, node:{type:queue}}'
Will create only one object (whichever one you put first). The second call will route to the existing object, regardless of the type-mismatch.
I wrote this chapter: http://deathstar1.usersys.redhat.com:8080/TopicIndex/Books/Messaging_Programming_Reference/index.html#chap-Beyond_Hello_World (can't push to stage atm) to try to address this issue. In this chapter I've given examples of creating exchanges and of subscribing to exchanges with queues. Hopefully this method of demonstration through repeated examples clarifies it somewhat. Needs technical review. Released for MRG 2.2 |
Description of problem: The addressing documentation is inadequate and even the upstream documents are not explicit enough. Here is an example of the confusion on addressing: 1) xyz; {create: always, node:{x-declare:{arguments:{'qpid.max_count':1000}}}} 2) xyz; {link:{x-declare:{arguments:{'qpid.max_count':500,'qpid.policy_type':'ring'}}} In 1) xyz is an exchange. We know we're creating a queue on this exchange because of the qpid.max_count. "This address only makes sense if it's an exchange" says ahem.. someone. In 2) xyz is a queue. why? cause we use link? Nope because of that qpid.max_count thing again. What exchange is it on? In both 1) and 2) we are creating a queue no matter what xyz is. we know this because of the qpid.max_count (only on queues). I guess I can create a fanout exchange using the node type of topic even though it's a fanout exchange and not a topic. But sure fanout is really only a specialization of topic. But only if you know that. The above two examples come form this wiki page. I just subsituted the names od the queue/excahgne with 'xyz' https://cwiki.apache.org/confluence/display/qpid/Addressing+Examples The point is that we have some more material than what's in the docs. NWe need to pull down the information from the wiki. However even that information needs to include some of the "magic" that goes on underneath or what to watch for. For example I imagine a lot of the time I might need to create a queue that doesn't have qpid.max_count. So is this true. Is there an address that I could look at and imagine that I don't know whether xyz is a queue or an exchange, that it would depend on if there is something already created with that name or not? I imagine that is true and therefore we need to understand what does the client/server do in that case. How does it decide if you are erroneously trying to create something or whether it will erroneously connect you to something that already exists? Is that possible? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: