The core AMQP 1.0 spec doesn't define a broker model in the way that previous versions did, it instead deals with the semantics of transfering messages over 'links' between 'nodes' that have an 'address' (can you see some of the inspiration for naming some of the previously discussed things?). A node could be thought of a producer/consumer in a client, or a queue/topic in a broker...or anything really, it is essentially just a named entity.
In terms of a 'topic', this needs to be something that supports the semantics of the pub-sub model, but there are a number of ways to achieve that. We currently have brokers that have models containing 'exchanges' that have been used for that historically (in confunction with queues) and so that is still the case, but utilising that model for 1.0 can require some unecessary hoop jumping (e.g exchanges are made to route messages to queues for consumers to receive, meanting that 'receiving from an exchange' can necessitate creation of temporary subscription queues to give the requested semantics) so going forward there is scope for alternative behaviours allowed by the 1.0 model. E.g one could represent a topic as a 'special' queue which only drops messages once all the consumers have passed it. Robbie On 13 February 2014 13:02, Jan Bares <jan.ba...@wood.cz> wrote: > Thanks Robbie, > > this is quite interesting stuff for QPID/AMQP newbies. How does this stuff > changes with AMQP 1.0? > > Thanks, Jan > > > -----Original Message----- > > From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] > > Sent: Wednesday, February 12, 2014 7:09 PM > > To: users@qpid.apache.org > > Subject: Re: New User JMS API Questions > > > > Hi Mark, > > > > Is your work email address registered on the list? if not the message may > > be awaiting moderation. > > > > Part of the issue is that you are definitely tripping up on a mixture of > > JNDI configuration, some of which is of the newer 'Address' syntax > variety > > and some which is of the older 'Binding URL' format supported by the JMS > > client. > > On top of that, you may be getting confused by the use of 'topic' as the > > type of an AMQP 0-x exchange, and the name of a node type in the > 'Address' > > syntax supported by the various Qpid clients, and finally its use in JMS > > and differing behaviour of the client depending on the syntax in use. > > > > On the terminology side: > > > > The 'topic' type of exchanges in AMQP 0-X support pattern matching for > > routing, whereas the other exchange types don't. The 'Address' syntax > uses > > the 'topic' to describe a node that can provide pub-sub semantics, and in > > the case of AMQP 0-10 that is taken to mean an exchange ~(of any type) > > with > > the name of the topic. The JMS client uses 'topic' in essentially the > same > > way when using the 'Address' syntax, but with the 'Binding URL' syntax > the > > topic name is used as the routing key when publishing the message to a > > particular exchange (whose name may be unrelated to the topic name, and > > usually is) or binding queues to the exchange to recieve messages. > > > > On the JMS client behaviour side: > > > > JNDI properties of the form "destination.<lookupname> = <value>" are > > treated as 'Address' strings by default, but may be treated as > BindingURLs > > if desired (see at the bottom). "queue.<lookupname> = <value>" and > > "topic.<lookupname> = <value>" values in the JNDI file are treated as a > > shorthand form of BindingURL that results in Queue usage with bindings > and > > publications to the amq.direct exchange using the queue name as the key, > > and Topic usage with bindings and publications to the amq.topic exchange > > using the topic name as the key. > > > > In your first test, by specifying "destination.topicExchange = > > news-service2" you thus got an 'Address' based Destination. The client > > 'resolves' the Address string against the broker when you create your > > producer/consumer to determine if the address is actually for a queue or > a > > topic (i.e an exchange) node. Prior to that it is returning null from the > > 'getTopicName' method, whereas looking at the code I expect it would > > return > > you the exchange name if you move that line down bit. > > > > On your second test, by using "topic.topicExchange = news-service2" you > > ended up with a BindingURL based Destination, which in this case told the > > client to use the "amq.topic" exchange and send the messages with a > routing > > key of "news-service2", and to bind a temporary queue to amq.topic with > > the > > binding key "new-service2". > > > > For your third test, using "queue.topicExchange = some_queue_name" got > > you > > a BindingURL based Destination, which told the client to use the > > "amq.direct" exchange and send the messages with a routing key of > > "some_queue_name". The consumer creation had the side effect of creating > > the queue and binding it ot the amq.direct exchange, because you were > > using > > a BindingURL based destination an this is the historic consumer behaviour > > the client had with that syntax. For the Address syntax, it doesnt do > that > > by default but you can make it do something similar using the options of > > the Address string. > > > > Some other info: > > > > You can see more details of the Address syntax at the following location, > > though it is more tailored to the C++ etc APIs and the JMS client doesn't > > necessarily support all of the options in the same way: > > http://qpid.apache.org/releases/qpid-0.24/programming/book/section- > > addresses.html > > > > Some details of the expanded BindingURL format usable in the > "destination." > > JNDI entries is at: > > https://cwiki.apache.org/confluence/display/qpid/BindingURLFormat > > > > You can change the clients default syntax at a client level by setting > the > > system property qpid.dest_syntax to the value BURL (or ADDR), or you can > > prefix the <value> part of the JNDI property to override the default, > using > > BURL: to indicate a BindingURL, or ADDR: to indicate an Address. > > > > Robbie > > > > On 12 February 2014 03:14, Mark Barker <mark.bar...@shaw.ca> wrote: > > > > > Apologies in advance if this shows up twice, but I seem to have had > > > problems sending from my work account... > > > > > > --- > > > > > > Hello. > > > > > > I have been playing around with the Hello.java example that came with > > > qpid-java-client-0.24.tar.gz. > > > I have installed the qpidd package (the broker) on a Ubuntu 12.04 LTS > > > platform along with the qpid-tools package > > > (from the Ubuntu Software Centre). > > > > > > I am looking to try and integrate the Qpid broker with JMS-based > clients. > > > I am brand new to all of the concepts and my > > > understanding is possibly being confused by the differences in > terminology > > > between JMS and Qpid elements. > > > I would greatly appreciate if you can indulge a few questions arising > from > > > my initial foray... > > > > > > By modifying the code to use the pub/sub API, I have arrived at this > > > source (Hello2.java): > > > > > > -------- > > > package org.apache.qpid.example; > > > import javax.jms.*; > > > import javax.naming.Context; > > > import javax.naming.InitialContext; > > > import java.util.Properties; > > > > > > public class Hello2 > > > { > > > public Hello2() > > > { > > > } > > > public static void main(String[] args) > > > { > > > Hello2 hello2 = new Hello2(); > > > hello2.runTest(); > > > } > > > private void runTest() > > > { > > > try { > > > Properties properties = new Properties(); > > > properties.load(this.getClass().getResourceAsStream("hello2. > > > properties")); > > > Context context = new InitialContext(properties); > > > TopicConnectionFactory topicConnectionFactory = > > > (TopicConnectionFactory) context.lookup("qpidConnectionfactory"); > > > TopicConnection topicConnection = topicConnectionFactory. > > > createTopicConnection(); > > > topicConnection.start(); > > > TopicSession topicSession = > > topicConnection.createTopicSession(false, > > > Session.AUTO_ACKNOWLEDGE); > > > Topic topic = (Topic) context.lookup("topicExchange"); > > > System.out.println(topic.getTopicName()); > > > > > > TopicPublisher topicPublisher = > topicSession.createPublisher( > > > topic); > > > TopicSubscriber topicSubscriber = > topicSession.createSubscriber( > > > topic); > > > TextMessage message = topicSession.createTextMessage("Hello > > > world!"); > > > topicPublisher.publish(message); > > > message = (TextMessage)topicSubscriber.receive(); > > > System.out.println(message.getText()); > > > topicConnection.close(); > > > context.close(); > > > } > > > catch (Exception exp) > > > { > > > exp.printStackTrace(); > > > } > > > } > > > } > > > -------- > > > > > > Now, hello2.properties looks like this: > > > -------- > > > java.naming.factory.initial = org.apache.qpid.jndi. > > > PropertiesFileInitialContextFactory > > > # register some connection factories > > > # connectionfactory.[jndiname] = [ConnectionURL] > > > connectionfactory.qpidConnectionfactory = > > amqp://guest:guest@clientid/? > > > brokerlist='tcp://localhost:5672' > > > # Register an AMQP destination in JNDI > > > # destination.[jniName] = [Address Format] > > > destination.topicExchange = news-service2 > > > #topic.topicExchange = news-service2 > > > -------- > > > > > > Before running the program, I adminstratively create the topic exchange > > > via qpid-config: > > > % qpid-config add exchange topic news-service2 > > > > > > Now... "AS-IS", the above code/properties combination "works" - i.e. > when > > > I compile and run Hello2.jar, I see this output: > > > -------- > > > null > > > Hello world! > > > -------- > > > > > > If I use the command-line "qpid-stat -e", I do indeed see msgIn and > > msgOut > > > counters incrementing for the "news-service2" > > > topic exchange. > > > What I don't understand (my first question) here is why the > > > "topic.getTopicName()" call is returning "null" in this instance? > > > > > > When I substitute "topic.topicExchange" for > "destination.topicExchange" in > > > the hello2.properties file, I get this output: > > > -------- > > > news-service2 > > > Hello world! > > > -------- > > > > > > Here, "topic.getTopicName()" actually returns the expected string > > > "news-service2". > > > However, in this case "qpid-stat-e" shows that the corresponding topic > > > exchange "news-service2" has NOT changed its > > > msgIn/msgOut counters, BUT the counts for amq.topic have changed > > instead. > > > My second question therefore is why have these > > > messages ended up in amq.topic? > > > > > > A final question (more of a related query). If I use the default > > > (original) example code Hello.java, but in hello.properties > > > substitute "destination.topicExchange = amq.topic" for > > > "queue.topicExchange = some_queue_name", I note that even if > > > "some_queue_name" did not exist in the broker prior to running Hello, > > then > > > it is created. This behaviour doesn't seem to work > > > for "topic.topicExchange" so I was wondering why the discrepancy. > > > > > > Thanks for indulging these newbie questions! > > > > > > Mark. > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > > > > > > DISCLAIMER > ________________________________ > WOOD & Company Financial Services, a.s. and its branches are > authorized and regulated by the CNB as Home State regulator and in Poland > by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State > regulators. For further information about WOOD & Co., its investment > services, financial instruments and associated risks, safeguard client > assets (incl. compensation schemes) and contractual relationship please see > our website at www.wood.com<http://www.wood.com/> under section Corporate > Governance. > Unless otherwise stated, this transmission is neither an offer > nor the solicitation of an offer to sell or purchase any investment. All > estimates, opinions and other information contained herein are subject to > change without notice and are provided in good faith but without legal > responsibility or liability. Opinion may be personal to the author and may > not reflect the opinions of WOOD & Co. Communications from sales persons, > sales traders or traders should not be regarded as investment research and > may contain opinions or trading ideas which are different from WOOD & Co. > investment research opinions. > This e-mail and any attachments are confidential and may be > privileged or otherwise protected from disclosure. If you are not a named > addressee you must not use, disclose, distribute, copy, print or rely on > this e-mail and any of its attachments. Please notify the sender that you > have received this email by mistake by replying to the email, and then > delete the email and any copies of it. Although WOOD & Co. routinely > screens e-mails for viruses, addressees should scan this e-mail and any > attachments for viruses. WOOD & Co. makes no representation or warranty as > to the absence of viruses in this e-mail or any attachments. Please note > that to ensure regulatory compliance and for the protection of our clients > and business, we may monitor and read e-mails sent to and from our > server(s). > ________________________________ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
