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
