@Robbie, thank you for clarification On Mon, Dec 7, 2015 at 1:07 PM, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> On 4 December 2015 at 19:09, Olivier Mallassi > <olivier.malla...@gmail.com> wrote: > > Hello all > > > > I am beginning to figure out how the JMS & AMQP specs. yet I am facing a > > copule of questions: > > > > *1/ competing & non competing consumers: * > > > > using amqp 0.10 and Jms destinations, I was able to publish my events on > > amq.topic/x.y.z > > and then to consume these events from different subscription queues A & > B, > > (using the binding x.*.z). > > > > on A, I can have competing consumers. on B also but no competition > between > > A & B. > > > > I am able to do the same with AMQP 1.0 by > > - pre configuring my queues on the broker (and then the consumers listen > to > > it) > > - publishing in a queue / topic (no difference) > > topic.myTopic=amq.topic/x.y.z or topic.myTopic=amq.topic and > > myJMSMessage.setJMSType("xyz"). both solution works since setJMSType is > > mapped to amqp subject. > > > > Is this the right way? > > It is certainly one way yes. > > I'm assuming that you are using the Java broker here based on your > mails. The core 1.0 spec only really deals with 'nodes' (e.g > queues/topics) that have an explicit 'address', which you attach > producers/consumers to (or utilise in the message 'to' field). The > java broker is actually interpreting the first address as an exchange > name + routing key because it has a "/" in it. When publishing to an > exchange using an address without the "/" it is then similarly looking > at the message Subject field and interpreting that as a routing key. > Both of these behaviours are essentially a way of mapping AMQP 1.0 > onto the older AMQP 0-x concepts of exchange+routing-key (which dont > exist in 1.0) the broker already supported thanks to implementing > those protocols. I think the C++ broker supports the latter of those > behaviours as well. > > > > Is there a way to dynamically create the queues (on consumer side) (with > > the equivalent of create:always)? > > > > The core AMQP 1.0 protocol has no built in facility to explicitly > create name queues etc (except 'dynamic' nodes, e.g temporary queues, > anmed by the broker) in the way that prior AMQP 0-x protocols did, as > it instead concentrated on getting messages from A to B rather than > defining an explicit broker model that must be implemented. There is > an effort at the OASIS AMQP TC to define a layered AMQP Management > specification that uses AMQP messaging to support implementing such > management operations (and many others). > > When recieveing from an exchange address, I believe the java broker > will make an implicit temporary queue to funnel messages to the > consumer. That process might (im not sure) support similar trickery > with "/" in the address to create that queue using a specific binding. > An alternative to that might be adding a selector on JMSType if the > messages all have a Subject set. Someone more familiar with the 1.0 > support in the Java broker might be able to add something here. > > If you want explicitly named queues with particular bindings, I think > you will need to create them in advance. > > > I observe that I cannot publish as long as there is no binding defined > (at > > the broker level). I got javax.jms.JMSException: Unknown error from > remote > > peer > > Is it expected? can I publish into the broker (previously exchange) even > if > > no bindings are defined? > > > > I'd guess whats happening here is that the message is being rejected > (without a specific error) due to the lack of binding, and the client > is interpreting that as a failure to send and reacting accordingly. > > Someone more familiar with the 1.0 support in the Java broker might be > able to add something here. > > > > > *2/ destination.<jndi_support> * > > Looking at that page, as MRG is based on cpp qpid ( > > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/3/html-single/Messaging_Programming_Reference/index.html#Apache_Qpid_JNDI_Properties_for_AMQP_Messaging > ) > > destination.<jndi name> are supported. > > > > Looking at the code, (and the JmsInitialContextFactory, it looks like > only > > queue. & topic. are supported. > > Yet, looking at the AmqpProducerBuilder.createEndpoint(), the target > > address is used, as is (based on the specified JmsDestination) and set > into > > the source. > > > > same for the Consumer. > > > > so the support for destination.<jndi name> looks doable and would give us > > the ability to define (in JMS) something like > > destination.myName= "amq.topic/#.news;{node:{capabilities:[shared]}, > > link:{name: 'news'}}" > > > > or to use amq.match. or benefit from the address schema ( > > > https://github.com/apache/qpid-proton/blob/master/proton-c/src/messaging.xml > > ) > > > > > > Am I wrong? Do I miss something? > > > > The new AMQP 1.0 client is entirely distinct from the earlier 0-x > client and does not support the old 'address syntax' it used. > Documentation for the client can be found on the website, e.g > http://qpid.apache.org/releases/qpid-jms-0.6.0/docs/index.html for the > current release. > > The "queue." and "topic." entries documented are all that the new > client currently supports, with the entry value currently mapping > directly to the AMQP 1.0 node 'address' as you have seen. > > Possibly adding expanded abilities to configure some lower level AMQP > details around e.g link options etc is something that has been > mentioned in passing during discussion of the AMQP JMS Mapping work > (which the client is implementing) at the OASIS AMQP Bindings & > Mappings TC, but it is not something that has yet been looked at. > > > > > *3/ guarantee delivery and message persistence. * > > > > AFAIU, if the message is marked JMSDeliveryMode.PERSISTENT, then it is > > marked as durable modulo the reliablity of the link/target. > > > > If the producer is set with peristent delivery mode (which the > default), or the send operation specifies it explicitly then the > message is marked durable during send. > > > Again, AFAIU, at the broker level, as long as my vhost is declared > durable > > (derby based for instance), my message will be persisted. so no message > > loss in case of restard of the broker. > > > > On the broker, the queue itself has a 'durable' configuration. > Messages are persisted when their queue is durable and the message is > also. > > > regarding the link, when a create the end point on the broker, I see the > > following log: > > > > > > 2015-12-04 15:10:08,670 DEBUG [IoReceiver - /192.168.56.102:60754] > (FRM) - > > RECV[/192.168.56.102:60754|1] : > > > Attach{name=qpid-jms:sender:ID:POMALLASSI-60751-1449239241646-0:1:1:1:amq.topic/x.y.z,handle=0,role=sender,s > > > *ndSettleMode=unsettled,rcvSettleMode=first,*source=Source{address=ID:POMALLASSI-60751-1449239241646-0:1:1:1,durable=none,expiryPolicy=session-end,timeout=0,dynamic=false,outcomes=[amqp:accepted:list, > > > amqp:rejected:list]},target=Target{address=amq.topic/x.y.z,durable=none,expiryPolicy=session-end,timeout=0,dynamic=false,capabilities=[queue]},incompleteUnsettled=false,initialDeliveryCount=0} > > > > > > - Why is my target defined as non durable? > > The 'target' is the AMQP 1.0 link terminus, not the node itself at the > address given (which in this case would actually be interpreted as an > exchange and routing key). > > > - looking at the settlemode, by default the AMQPProducerBuidler set the > > settle-mode à unsettled (and it looks related to AMQPProvider). can I > > change this mode using the property amqp.preSettleProducers? > > - Is this is only 'properties' that gives me guarantee delivery? > > > > Setting that property (which has not been documented as it isnt > especially tested and the related functionality may yet change), which > would change the producers to send messages 'pre-settled'. Doing that > would mean they are essentially forgotten about by the client > immediately as it sends them (before the send method returns), and the > broker isnt able to indicate anything about whether it received them > or not. > > > > > Sorry for that long email and thanks for you help. then will have to > > integrate all of this with the router. > > > > > > Regards. > > > > > > oliv/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >