@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
>
>
