You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Rabih M <ra...@gmail.com> on 2017/01/17 16:03:06 UTC
[Qpid Dispatch] Manage Dispatch router from Qpid Jms
Hello,
If I understood well, Qpid-Dispatch can be managed using Amqp messages.
I saw that the management code is based on proton python binding.
Do you think it is feasible to manage the dispatch router the same way from
Qpid-Jms api?
Was there any work done in this direction before? Will it be too
complicated to do it?
Thanks,
Rabih
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Ganesh Murthy <gm...@redhat.com>.
----- Original Message -----
> From: "Robbie Gemmell" <ro...@gmail.com>
> To: users@qpid.apache.org
> Sent: Wednesday, February 15, 2017 10:07:07 AM
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> On 15 February 2017 at 14:15, Adel Boutros <Ad...@live.com> wrote:
> > Hello guys,
> >
> >
> > Based on the discussion, we are currently writing a Java API based on JMS
> > to configure the dispatch router. I have so far managed to do the
> > following:
> >
> > * Create, Read, Delete addresses
> >
> > * Create, Read, Delete connectors
> >
> >
> > Config:
> >
> > Dispatch Router 0.7.0
> >
> > JMS 0.11.1
> >
> >
> > And I have noticed some problems and differences:
> >
> >
> > 1) It seems some calls return ObjectMessage and some TextMessage (This is
> > on the side of the consumer in the replyTo)
> >
> > For example, creating twice the same queue will fail but the second call
> > will return a JmsTextMessage with an empty body and status code 400
> >
>
> The client treats messages with an amqp-value sectioning containing
> null/nothing as a TextMessage with null value if they arent annotated
> to say otherwise, I'd guess thats where that comes from.
>
> >
> > 2) Returned statusCode differs between Connector and Address
> >
> > Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
> >
> >
> > * Connector operations return java.lang.Long
> > * Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
> >
>
> The router is presumably sending different values back for the
> different operations here, a long and a uint. The router should
> perhaps be consistent, and the client should perhaps not be returning
> the uint object either way.
>
> The last draft of the management spec seems to say the status code
> should be 'integer', im not clear if it means int (not uint)
> specifically, or just any integral type value.
The connector create operation is handled by the Python agent and the address create operation is handled by the c agent.
Both should be returning consistent int values for status codes. I have entered a JIRA for this -
https://issues.apache.org/jira/browse/DISPATCH-633
>
> >
> > 3) Create connector twice makes dispatch router crash. I don't have the
> > issue when creating addresses.
I think I have seen this crash before and I believe that this has been fixed in the master branch.
Thanks.
> > On the second create call, JMS client receives a normal reply containing a
> > statusCode of an exception. After I close the connection to the dispatch
> > router via JMS (connection.close), I have the below crash
> >
> > (gdb) where
> > #0 0x00007f27194448a5 in raise () from /lib64/libc.so.6
> > #1 0x00007f2719446085 in abort () from /lib64/libc.so.6
> > #2 0x00007f27194827b7 in __libc_message () from /lib64/libc.so.6
> > #3 0x00007f27194880e6 in malloc_printerr () from /lib64/libc.so.6
> > #4 0x00007f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf
> > expression opcode 0xf3
> > ) at /qpid-dispatch-0.7.0/src/hash.c:320
> > #5 0x00007f271a42247d in qdr_route_check_id_for_deletion_CT
> > (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
> > ) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
> > #6 0x00007f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30,
> > action=Unhandled dwarf expression opcode 0xf3
> > ) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
> > #7 0x00007f271a423f30 in router_core_thread (arg=0x13d2d30) at
> > /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
> > #8 0x00007f2719f8c851 in start_thread () from /lib64/libpthread.so.0
> > #9 0x00007f27194fa90d in clone () from /lib64/libc.so.6
> >
> >
> > Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE:
> > org.apache.qpid.dispatch.connector: Duplicate value
> > 'connector/127.0.0.1:5915:dispatch_management_connector_test' for unique
> > attribute 'identity'
> > *** glibc detected *** /Dispatch/sbin/qdrouterd: double free or corruption
> > (fasttop): 0x00007f2708033f10 ***
> > ======= Backtrace: =========
> > /lib64/libc.so.6(+0x760e6)[0x7f27194880e6]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch.so(qd_hash_remove_by_handle+0x29)[0x7f271a40f109]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch.so(+0x3547d)[0x7f271a42247d]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch.so(+0x318d3)[0x7f271a41e8d3]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch.so(router_core_thread+0x230)[0x7f271a423f30]
> > /lib64/libpthread.so.0(+0x7851)[0x7f2719f8c851]
> > /lib64/libc.so.6(clone+0x6d)[0x7f27194fa90d]
> > ======= Memory map: ========
> > 00400000-00403000 r-xp 00000000 fd:01 7735642
> > /Dispatch/sbin/qdrouterd
> > 00603000-00604000 rw-p 00003000 fd:01 7735642
> > /Dispatch/sbin/qdrouterd
> > 01113000-01458000 rw-p 00000000 00:00 0
> > [heap]
> > 7f26f8000000-7f26f805c000 rw-p 00000000 00:00 0
> > 7f26f805c000-7f26fc000000 ---p 00000000 00:00 0
> > 7f26fc000000-7f26fc043000 rw-p 00000000 00:00 0
> > 7f26fc043000-7f2700000000 ---p 00000000 00:00 0
> > 7f2700000000-7f2700085000 rw-p 00000000 00:00 0
> > 7f2700085000-7f2704000000 ---p 00000000 00:00 0
> > 7f27073e9000-7f27073ff000 r-xp 00000000 fd:00 524293
> > /lib64/libgcc_s-4.4.7-20120601.so.1
> > 7f27073ff000-7f27075fe000 ---p 00016000 fd:00 524293
> > /lib64/libgcc_s-4.4.7-20120601.so.1
> > 7f27075fe000-7f27075ff000 rw-p 00015000 fd:00 524293
> > /lib64/libgcc_s-4.4.7-20120601.so.1
> > 7f27075ff000-7f2707600000 ---p 00000000 00:00 0
> > 7f2707600000-7f2708000000 rw-p 00000000 00:00 0
> > 7f2708000000-7f270805a000 rw-p 00000000 00:00 0
> > 7f270805a000-7f270c000000 ---p 00000000 00:00 0
> > 7f270c04a000-7f270c04f000 r-xp 00000000 fd:00 524322
> > /lib64/libnss_dns-2.12.so
> > 7f270c04f000-7f270c24e000 ---p 00005000 fd:00 524322
> > /lib64/libnss_dns-2.12.so
> > 7f270c24e000-7f270c24f000 r--p 00004000 fd:00 524322
> > /lib64/libnss_dns-2.12.so
> > 7f270c24f000-7f270c250000 rw-p 00005000 fd:00 524322
> > /lib64/libnss_dns-2.12.so
> > 7f270c250000-7f270c251000 ---p 00000000 00:00 0
> > 7f270c251000-7f270cc51000 rw-p 00000000 00:00 0
> > 7f270cc51000-7f270cc52000 ---p 00000000 00:00 0
> > 7f270cc52000-7f270d652000 rw-p 00000000 00:00 0
> > 7f270d652000-7f270d65e000 r-xp 00000000 fd:00 524324
> > /lib64/libnss_files-2.12.so
> > 7f270d65e000-7f270d85e000 ---p 0000c000 fd:00 524324
> > /lib64/libnss_files-2.12.so
> > 7f270d85e000-7f270d85f000 r--p 0000c000 fd:00 524324
> > /lib64/libnss_files-2.12.so
> > 7f270d85f000-7f270d860000 rw-p 0000d000 fd:00 524324
> > /lib64/libnss_files-2.12.so
> > 7f270d86a000-7f270d86b000 ---p 00000000 00:00 0
> > 7f270d86b000-7f270e3ac000 rw-p 00000000 00:00 0
> > 7f270e3ac000-7f270e3b1000 r-xp 00000000 00:16 4090944
> > /python278/lib/python2.7/lib-dynload/select.so
> > 7f270e3b1000-7f270e5b0000 ---p 00005000 00:16 4090944
> > /python278/lib/python2.7/lib-dynload/select.so
> > 7f270e5b0000-7f270e5b2000 rw-p 00004000 00:16 4090944
> > /python278/lib/python2.7/lib-dynload/select.so
> > 7f270e5b2000-7f270e5b6000 r-xp 00000000 00:16 5568743
> > /python278/lib/python2.7/lib-dynload/_lsprof.so
> > 7f270e5b6000-7f270e7b5000 ---p 00004000 00:16 5568743
> > /python278/lib/python2.7/lib-dynload/_lsprof.so
> > 7f270e7b5000-7f270e7b6000 rw-p 00003000 00:16 5568743
> > /python278/lib/python2.7/lib-dynload/_lsprof.so
> > 7f270e7b6000-7f270e8b7000 rw-p 00000000 00:00 0
> > 7f270e8b7000-7f270e8bc000 r-xp 00000000 00:16 6394000
> > /python278/lib/python2.7/lib-dynload/strop.so
> > 7f270e8bc000-7f270eabb000 ---p 00005000 00:16 6394000
> > /python278/lib/python2.7/lib-dynload/strop.so
> > 7f270eabb000-7f270eabd000 rw-p 00004000 00:16 6394000
> > /python278/lib/python2.7/lib-dynload/strop.so
> > 7f270eabd000-7f270eafd000 rw-p 00000000 00:00 0
> > 7f270eafd000-7f270eb00000 r-xp 00000000 00:16 5568749
> > /python278/lib/python2.7/lib-dynload/fcntl.so
> > 7f270eb00000-7f270ecff000 ---p 00003000 00:16 5568749
> > /python278/lib/python2.7/lib-dynload/fcntl.so
> > 7f270ecff000-7f270ed01000 rw-p 00002000 00:16 5568749
> > /python278/lib/python2.7/lib-dynload/fcntl.so
> > 7f270ed01000-7f270ed04000 r-xp 00000000 00:16 5568739
> > /python278/lib/python2.7/lib-dynload/_random.so
> > 7f270ed04000-7f270ef03000 ---p 00003000 00:16 5568739
> > /python278/lib/python2.7/lib-dynload/_random.so
> > 7f270ef03000-7f270ef04000 rw-p 00002000 00:16 5568739
> > /python278/lib/python2.7/lib-dynload/_random.so
> > 4272 Aborted (core dumped)
> >
> >
> > Regards,
> > Adel
> >
> >
> > ________________________________
> > From: Rob Godfrey <ro...@gmail.com>
> > Sent: Monday, February 6, 2017 7:09 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >
> > On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
> > wrote:
> >
> >> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com> wrote:
> >> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
> >> >
> >> >> It seems odd that the client creates a _sender_ to the temporary queue
> >> >> that it will never send messages _to_ but will receive messages _from_.
> >> >>
> >> >>
> >> > This is because JMS semantics require the temporary node to have a
> >> lifetime
> >> > scoped to the session (not a link), so the JMS client has to create a
> >> > synthetic link which it uses simply to manage the lifetime of the
> >> > dynamic
> >> > node. In order to not cause unintentional assigning of messages to a
> >> link
> >> > that will never actually be used for consumption, a sending link is
> >> > used.
> >> > Note that in general JMS would expect that you should be able to send to
> >> a
> >> > temporary queue created in this way (since the point of temporary queues
> >> is
> >> > to use as a reply to)
> >> >
> >>
> >> Not really important here, but the lifetime is scoped to the
> >> Connection, not Session (agghhh JMS... :P)
> >>
> >
> > That's what I thought I was typing... obviously my fingers were not
> > cooperating with my brain at that point :-)
> >
> > -- Rob
> >
> >
> >>
> >> >
> >> >> Anyway, when the client creates a receiver with a dynamic source (and
> >> >> no
> >> >> dynamic-node-properties), the router will accept the link and assign a
> >> >> temporary address as the source. This is only useful in this use case
> >> if
> >> >> the broker has a way of knowing that the temporary address is reachable
> >> via
> >> >> the router network.
> >> >>
> >> >> There is a way to route dynamic termini to a broker. If an
> >> >> x-opt-qd.address property is included in the dynamic-node-properties,
> >> this
> >> >> address will be used to route the attach to the broker. I've never
> >> tested
> >> >> this with a dynamic target in a sender. It might not work.
> >> >
> >> >
> >> > And this really isn't something you'd be expecting a generic client
> >> > (like
> >> > the JMS client) to know :-)
> >> >
> >> > -- Rob
> >> >
> >> >
> >> >>
> >> >>
> >> >> -Ted
> >> >>
> >> >>
> >> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
> >> >>
> >> >>> I've had a look at this. It would seem that Dispatch doesn't like what
> >> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
> >> >>> very nice way, and the client then doesnt notice that things have gone
> >> >>> south in a somewhat unexpected way.
> >> >>>
> >> >>> The client opens a sending link with 'dynamic' target in order to
> >> >>> create a dynamic node for use as a TemporaryQueue address/destination
> >> >>> object, which specific consumers/producers are then created against by
> >> >>> the application. Dispatch doesn't seem to like that but erroneously
> >> >>> attaches the link 'successfully', though doesnt set a target address
> >> >>> as is expected. The client then doesnt notice this happened (its
> >> >>> checking for the link being refused, which it wasn't), allowing the
> >> >>> application to proceed as far as creating consumers/procuers using the
> >> >>> TemporaryQueue object, with creation of the e.g Consumer then failing
> >> >>> since the attach doesnt contain the needed information and leads to
> >> >>> Dispatch detaching it with the error (though it again doesnt actually
> >> >>> indicate its refusing the link during the attach response, as it
> >> >>> probably should have in this case).
> >> >>>
> >> >>> Making the client detect the current failure and having it throw an
> >> >>> aexception from createTemporaryQueue is simple enough.
> >> >>>
> >> >>> Hacking the client to use a dynamic recieving link instead, an address
> >> >>> was returned by Dispatch in the attach response as expected, however a
> >> >>> consumer on the resulting TemporaryQueue object using this address
> >> >>> still didnt get the message I sent to the same place. If I also gave
> >> >>> some credit on the link backing the TemporaryQeueue object itself then
> >> >>> that link gets sent the message by Dispatch, though this of no use for
> >> >>> the JMS client.
> >> >>>
> >> >>> Needs some more investigation, and I'll need to discuss with some
> >> >>> folks more familiar with Dispatch.
> >> >>>
> >> >>> Robbie
> >> >>>
> >> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
> >> wrote:
> >> >>>
> >> >>>> Hello Robbie,
> >> >>>>
> >> >>>>
> >> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the
> >> >>>> reply
> >> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS
> >> >>>> Client.
> >> >>>>
> >> >>>>
> >> >>>> PS: As Rabih stated before, we are using the same connection and same
> >> >>>> session to create the JMSProducer for the request and the
> >> JMSConsumer for
> >> >>>> the reply.
> >> >>>>
> >> >>>>
> >> >>>> Exception
> >> >>>> -------------------
> >> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed due
> >> to
> >> >>>> an unrecoverable error.
> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
> >> >>>> eConsumer.java:330)
> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
> >> >>>> sumer.java:196)
> >> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> >> >>>> ssorImpl.java:62)
> >> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> >> >>>> thodAccessorImpl.java:43)
> >> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
> >> >>>> at com.intellij.rt.execution.application.AppMain.main(
> >> AppMain.java:147)
> >> >>>> Caused by: javax.jms.JMSException: No route to the destination node
> >> >>>> [condition = qd:no-route-to-dest]
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >> >>>> tion(AmqpSupport.java:150)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >> >>>> tion(AmqpSupport.java:105)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
> >> >>>> elyClosed(AmqpAbstractResource.java:147)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
> >> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
> >> >>>> s(AmqpProvider.java:795)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
> >> >>>> mqpProvider.java:90)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
> >> >>>> ovider.java:699)
> >> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
> >> >>>> Executors.java:511)
> >> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
> >> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> >> >>>> Executor.java:1142)
> >> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> >> >>>> lExecutor.java:617)
> >> >>>> at java.lang.Thread.run(Thread.java:745)
> >> >>>>
> >> >>>>
> >> >>>> -------------------
> >> >>>> Dispatch Router (PN_TRACE_FRM=1)
> >> >>>> -------------------
> >> >>>>
> >> >>>> [832220]: <- SASL
> >> >>>> [832220]: -> SASL
> >> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
> >> >>>> MBOL[:ANONYMOUS]]
> >> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
> >> >>>> initial-response=b"", hostname="host-name"]
> >> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
> >> >>>> [832220]: <- AMQP
> >> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
> >> a334-44c3-954a-2dd910161411:1",
> >> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
> >> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
> >> >>>> L[:"sole-connection-for-container"], properties={:product="QpidJMS",
> >> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
> >> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
> >> >>>> [832220]: -> AMQP
> >> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
> >> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> >> >>>> offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-
> >> dispatch-router",
> >> >>>> :version="0.7.0"}]
> >> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> >> >>>> outgoing-window=2147483647, handle-max=65535]
> >> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
> >> >>>> incoming-window=61, outgoing-window=2147483647]
> >> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> >> >>>> outgoing-window=2147483647, handle-max=65535]
> >> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
> >> >>>> incoming-window=61, outgoing-window=2147483647]
> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]],
> >> >>>> target=@target(41) [address="$management", durable=0,
> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
> >> >>>> initial-delivery-count=0]
> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
> >> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list",
> >> >>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
> >> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
> >> queue]],
> >> >>>> initial-delivery-count=0, max-message-size=0]
> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> delivery-count=0,
> >> >>>> link-credit=250, drain=false]
> >> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> >> [],
> >> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
> >> timeout=0,
> >> >>>> dynamic=true, dynamic-node-properties={:"lif
> >> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
> >> temporary-queue"]],
> >> >>>> incomplete-unsettled=false, initial-delivery-count=0]
> >> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> >> role=true,
> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
> >> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []},
> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
> >> initial-delivery-count=0,
> >> >>>> max-message-size=0]
> >> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> delivery-count=0,
> >> >>>> link-credit=250, drain=false]
> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=true,
> >> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [durable=0,
> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> >> >>>> default-outcome=@modified(39) [delivery-failed=true],
> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> >> >>>> :"amqp:released:list", :"amqp:modified:list"],
> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41) []]
> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=false,
> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0,
> >> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
> >> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
> >> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
> >> >>>> destination node"]]
> >> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
> >> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
> >> delivery-tag=b"0",
> >> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
> >> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
> >> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
> >> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
> >> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
> >> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
> >> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
> >> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
> >> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
> >> >>>> x04addr\xa1\x0dbrokerMachine"
> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> delivery-count=1,
> >> >>>> link-credit=250, drain=false]
> >> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
> >> >>>> settled=true, state=@accepted(36) []]
> >> >>>> [832220]:0 <- @close(24) []
> >> >>>> [832220]: <- EOS
> >> >>>> [832220]:0 -> @close(24) []
> >> >>>> [832220]: -> EOS
> >> >>>> Closed x.x.x.x:8961
> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >> >>>>
> >> >>>> ------------------
> >> >>>> JMS Client (PN_TRACE_FRM=1)
> >> >>>> ------------------
> >> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
> >> 4a22-9b22-69d27a017a83:1',
> >> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
> >> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
> >> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
> >> connection-for-container],
> >> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM: 1.8.0_111,
> >> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
> >> >>>> [1244186219:0] <- Open{ containerId='router.10200', hostname='null',
> >> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
> >> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
> >> ANONYMOUS-RELAY],
> >> >>>> desiredCapabilities=null, properties={product=qpid-dispatch-router,
> >> >>>> version=0.7.0}}
> >> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> >> 3293ffc57168:1:1:1',
> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> >> amqp:rejected:list],
> >> >>>> capabilities=null}, target=Target{address='$management',
> >> durable=NONE,
> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> >> maxMessageSize=null,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> >> 3293ffc57168:1:1:1',
> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> >> amqp:rejected:list],
> >> >>>> capabilities=null}, target=Target{address='$management',
> >> durable=NONE,
> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> deliveryCount=0,
> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> properties=null}
> >> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> outcomes=null,
> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> >> maxMessageSize=null,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> outcomes=null,
> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> deliveryCount=0,
> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> properties=null}
> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE, expiryPolicy=LINK_DETACH,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
> >> deliveryFailed=true,
> >> >>>> undeliverableHere=null, messageAnnotations=null},
> >> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list,
> >> >>>> amqp:modified:list], capabilities=[temporary-queue]},
> >> >>>> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> capabilities=null},
> >> >>>> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
> >> >>>> maxMessageSize=null, offeredCapabilities=null,
> >> desiredCapabilities=null,
> >> >>>> properties=null}
> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> outcomes=null,
> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
> >> >>>> error=Error{condition=qd:no-route-to-dest, description='No route to
> >> the
> >> >>>> destination node', info=null}}
> >> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
> >> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
> >> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
> >> state=null,
> >> >>>> resume=false, aborted=false, batchable=false} (312)
> >> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
> >> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
> >> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@
> >> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
> >> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
> >> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
> >> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
> >> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
> >> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
> >> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> deliveryCount=1,
> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> properties=null}
> >> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
> >> >>>> settled=true, state=Accepted{}, batchable=false}
> >> >>>> [1244186219:0] -> Close{error=null}
> >> >>>> [1244186219:0] <- Close{error=null}
> >> >>>>
> >> >>>> Regards,
> >> >>>>
> >> >>>> Adel
> >> >>>>
> >> >>>> ________________________________
> >> >>>> From: Robbie Gemmell <ro...@gmail.com>
> >> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
> >> >>>> To: users@qpid.apache.org
> >> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >> >>>>
> >> >>>> That looks fine at first glance. Its possible there is an issue in
> >> >>>> there needing looked it. I am travelling this week so may not get to
> >> >>>> look until afterwards, but will try to give things a look at. If you
> >> >>>> could give more detail on the exception and maybe a protocol trace
> >> >>>> that might be useful.
> >> >>>>
> >> >>>> Robbie
> >> >>>>
> >> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
> >> >>>>
> >> >>>>> Hello Robbie,
> >> >>>>>
> >> >>>>> Thanks for you for your answer.
> >> >>>>> I will try the solutions you proposed.
> >> >>>>>
> >> >>>>> I need just need one clarification. Concerning the Jms, I already
> >> tried
> >> >>>>> to
> >> >>>>> use a temporary queue but it didn't work. May be i am using it
> >> >>>>> wrong.
> >> >>>>> Here
> >> >>>>> is what i did:
> >> >>>>>
> >> >>>>> ...
> >> >>>>> Session session = connection.createSession(false,
> >> >>>>> Session.AUTO_ACKNOWLEDGE);
> >> >>>>> Queue queue = session.createQueue("$management");
> >> >>>>> MessageProducer producer = session.createProducer(queue);
> >> >>>>>
> >> >>>>> Queue tempDest = session.createTemporaryQueue();
> >> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDest);
> >> >>>>> connection.start();
> >> >>>>>
> >> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
> >> >>>>> objectMessage.setJMSReplyTo(tempDest);
> >> >>>>> //fill the rest of the parameters ...
> >> >>>>> producer.send(objectMessage);
> >> >>>>> ObjectMessage replyMessage = (ObjectMessage)
> >> >>>>> responseConsumer.receive(1000);
> >> >>>>> ...
> >> >>>>>
> >> >>>>> I was getting an exception on the .receive() from the dispatch
> >> >>>>> router
> >> >>>>> saying that the reply-to address is bad...
> >> >>>>> Should i create the temporary queue and the consumer from a
> >> >>>>> different
> >> >>>>> session then the producer?
> >> >>>>>
> >> >>>>> Best regards,
> >> >>>>> Rabih
> >> >>>>>
> >> >>>>>
> >> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
> >> >>>>> robbie.gemmell@gmail.com>
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>> The session.createTemporaryQueue(); method is how JMS creates
> >> >>>>>> temporary destinations for use in reply-to scenarios. The dispatch
> >> >>>>>> tools will be doing essentially the same thing under the covers for
> >> >>>>>> theirs.
> >> >>>>>>
> >> >>>>>> Both work by creating a 'dynamic' link attachment, with the server
> >> >>>>>> returning an address for the dynamic attach to the client. One key
> >> >>>>>> difference is with JMS you create the temporary destination (for
> >> which
> >> >>>>>> the client uses a dynamic sender link to create), then separately
> >> >>>>>> create a receiver using it (and in turn the address associated with
> >> >>>>>> it), whereas non-JMS client/tools will typically just create a
> >> single
> >> >>>>>> dynamic receiver link and use its address for the reply-to.
> >> >>>>>>
> >> >>>>>> For proton-j, there aren't any examples for this, but you you
> >> >>>>>> essentially would change the link opening to not specify an
> >> >>>>>> address,
> >> >>>>>> and instead set the source(for a receiver) or target (for a sender)
> >> to
> >> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
> >> remoteTarget
> >> >>>>>> once the link had been reemotely attached, and get its
> >> >>>>>> (server-generated) address, then use this as your reply-to.
> >> >>>>>>
> >> >>>>>> Robbie
> >> >>>>>>
> >> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
> >> wrote:
> >> >>>>>>
> >> >>>>>>> Hello,
> >> >>>>>>>
> >> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like
> >> >>>>>>> you
> >> >>>>>>> suggested, it worked.
> >> >>>>>>> But I cheated a little to make it work because I did not find a
> >> way in
> >> >>>>>>>
> >> >>>>>> JMS
> >> >>>>>>
> >> >>>>>>> to create a local queue. So I created a queue on the qpid-dispatch
> >> and
> >> >>>>>>>
> >> >>>>>> read
> >> >>>>>>
> >> >>>>>>> the result from it. You can check the attached code.
> >> >>>>>>>
> >> >>>>>>> Is there any way using qpid-jms to create a local queue on the
> >> client
> >> >>>>>>>
> >> >>>>>> side
> >> >>>>>>
> >> >>>>>>> to serve as a reply to address?
> >> >>>>>>>
> >> >>>>>>> For the proton-j test, I have the same question as above. I saw
> >> that
> >> >>>>>>> it
> >> >>>>>>>
> >> >>>>>> can
> >> >>>>>>
> >> >>>>>>> be done with the C++ API. Are there any examples for proton-j or
> >> >>>>>>>
> >> >>>>>> something
> >> >>>>>>
> >> >>>>>>> that can help me?
> >> >>>>>>>
> >> >>>>>>> I saw may be in proton we don't need a local queue, may be we can
> >> get
> >> >>>>>>> the
> >> >>>>>>> address of the consumer directly and pass it in reply-to field. Is
> >> it
> >> >>>>>>> correct?
> >> >>>>>>>
> >> >>>>>>> Thanks,
> >> >>>>>>> Rabih
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
> >> >>>>>>> rob.j.godfrey@gmail.com>
> >> >>>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com>
> >> >>>>>>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> ----- Original Message -----
> >> >>>>>>>>>
> >> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
> >> >>>>>>>>>> To: users@qpid.apache.org
> >> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
> >> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid
> >> Jms
> >> >>>>>>>>>>
> >> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
> >> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you
> >> told
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>> me
> >> >>>>>>
> >> >>>>>>> Robbie and it worked.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> But like the proton-j case, the connector is not being
> >> created on
> >> >>>>>>>>>>>> the
> >> >>>>>>>>>>>> Qpid-dispatch side.
> >> >>>>>>>>>>>> I attached the amqp communication into this mail.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> The last frame in that file is incomplete (the previous error
> >> >>>>>>>>>>>
> >> >>>>>>>>>> regarding the
> >> >>>>>>>>>
> >> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
> >> frame
> >> >>>>>>>>>>>
> >> >>>>>>>>>> is
> >> >>>>>>
> >> >>>>>>> likely
> >> >>>>>>>>>
> >> >>>>>>>>>> the response which would indicate the success or otherwise of
> >> the
> >> >>>>>>>>>>>
> >> >>>>>>>>>> frame. Is
> >> >>>>>>>>>
> >> >>>>>>>>>> there anything logged by the router?
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
> >> simpler
> >> >>>>>>>>>>> for
> >> >>>>>>>>>>>
> >> >>>>>>>>>> this
> >> >>>>>>>>>
> >> >>>>>>>>>> sort of thing in my view.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more
> >> >>>>>>>>>> helpful.
> >> >>>>>>>>>> You
> >> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
> >> since
> >> >>>>>>>>>> it
> >> >>>>>>>>>> uses proton-j.
> >> >>>>>>>>>>
> >> >>>>>>>>>> One key difference from the qdmanage case is you are not
> >> setting a
> >> >>>>>>>>>> reply-to value or correlation-id to use along with it. I don't
> >> know
> >> >>>>>>>>>>
> >> >>>>>>>>> if
> >> >>>>>>
> >> >>>>>>> the router cares about not being able to send a response or not
> >> >>>>>>>>>> though, but it might.
> >> >>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> You could add the following to your dispatch router conf file
> >> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable trace
> >> >>>>>>>>>
> >> >>>>>>>> logging)
> >> >>>>>>
> >> >>>>>>>
> >> >>>>>>>>> log {
> >> >>>>>>>>> module: DEFAULT
> >> >>>>>>>>> enable: trace+
> >> >>>>>>>>> output: /path/to/log/qdrouterd.log
> >> >>>>>>>>> }
> >> >>>>>>>>>
> >> >>>>>>>>> When you run your management request, you will see proton frame
> >> >>>>>>>>> trace
> >> >>>>>>>>> and
> >> >>>>>>>>> you will see additional logging out of the dispatch Python agent
> >> -
> >> >>>>>>>>> something like the following -
> >> >>>>>>>>>
> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
> >> >>>>>>>>> Message(address=None,
> >> >>>>>>>>> properties={'operation': 'CREATE', 'type':
> >> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
> >> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
> >> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
> >> >>>>>>>>>
> >> >>>>>>>> 'rabih.connector'},
> >> >>>>>>
> >> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
> >> >>>>>>>>> correlation_id=1L)
> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
> >> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
> >> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
> >> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
> >> 5673:rabih.connector,
> >> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
> >> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
> >> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
> >> >>>>>>>>> verifyHostName=True)
> >> >>>>>>>>>
> >> >>>>>>>>> The Python management agent will not process your request if
> >> there
> >> >>>>>>>>> is
> >> >>>>>>>>>
> >> >>>>>>>> no
> >> >>>>>>
> >> >>>>>>> reply_to as seen here -
> >> >>>>>>>>>
> >> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
> >> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
> >> because
> >> >>>>>>>> there
> >> >>>>>>>> is
> >> >>>>>>>> a reply-to doesn't mean that the sender will be around to
> >> >>>>>>>> actually
> >> >>>>>>>> hear
> >> >>>>>>>> the
> >> >>>>>>>> reply, so it seems a bit arbitrary to say that because we *know*
> >> the
> >> >>>>>>>> sender
> >> >>>>>>>> won't learn of the outcome that we won't do anything... The spec
> >> >>>>>>>> draft
> >> >>>>>>>> doesn't currently say anything about this (obviously it should
> >> do),
> >> >>>>>>>> but
> >> >>>>>>>>
> >> >>>>>>> my
> >> >>>>>>
> >> >>>>>>> expectation would certainly be that a request would be processed
> >> even
> >> >>>>>>>> if
> >> >>>>>>>> the replyTo address was not present (or ended up not routing
> >> >>>>>>>> anywhere).
> >> >>>>>>>> This is also how the Qpid Broker for Java implements this case.
> >> >>>>>>>>
> >> >>>>>>>> -- Rob
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> Thanks.
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>> Robbie
> >> >>>>>>>>>>
> >> >>>>>>>>>> ------------------------------------------------------------
> >> >>>>>>>>>>
> >> >>>>>>>>> ---------
> >> >>>>>>
> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>> ------------------------------------------------------------
> >> >>>>>>>>> ---------
> >> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> ------------------------------------------------------------
> >> ---------
> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> ------------------------------------------------------------
> >> ---------
> >> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>
> >> >>>>
> >> >>> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>
> >> >>>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Ted Ross <tr...@redhat.com>.
On 02/06/2017 12:50 PM, Rob Godfrey wrote:
> On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
>
>> It seems odd that the client creates a _sender_ to the temporary queue
>> that it will never send messages _to_ but will receive messages _from_.
>>
>>
> This is because JMS semantics require the temporary node to have a lifetime
> scoped to the session (not a link), so the JMS client has to create a
> synthetic link which it uses simply to manage the lifetime of the dynamic
> node. In order to not cause unintentional assigning of messages to a link
> that will never actually be used for consumption, a sending link is used.
> Note that in general JMS would expect that you should be able to send to a
> temporary queue created in this way (since the point of temporary queues is
> to use as a reply to)
Actually, that makes sense. Clearly there's at least one Router bug
associated with dynamic targets.
>
>
>> Anyway, when the client creates a receiver with a dynamic source (and no
>> dynamic-node-properties), the router will accept the link and assign a
>> temporary address as the source. This is only useful in this use case if
>> the broker has a way of knowing that the temporary address is reachable via
>> the router network.
>>
>> There is a way to route dynamic termini to a broker. If an
>> x-opt-qd.address property is included in the dynamic-node-properties, this
>> address will be used to route the attach to the broker. I've never tested
>> this with a dynamic target in a sender. It might not work.
>
>
> And this really isn't something you'd be expecting a generic client (like
> the JMS client) to know :-)
Correct. We need a standard solution so generic clients will know what
to do (or a way to make current generic clients just work).
>
> -- Rob
>
>
>>
>>
>> -Ted
>>
>>
>> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
>>
>>> I've had a look at this. It would seem that Dispatch doesn't like what
>>> the client is doing for createTemporaryQueue, but doesn't fail in a
>>> very nice way, and the client then doesnt notice that things have gone
>>> south in a somewhat unexpected way.
>>>
>>> The client opens a sending link with 'dynamic' target in order to
>>> create a dynamic node for use as a TemporaryQueue address/destination
>>> object, which specific consumers/producers are then created against by
>>> the application. Dispatch doesn't seem to like that but erroneously
>>> attaches the link 'successfully', though doesnt set a target address
>>> as is expected. The client then doesnt notice this happened (its
>>> checking for the link being refused, which it wasn't), allowing the
>>> application to proceed as far as creating consumers/procuers using the
>>> TemporaryQueue object, with creation of the e.g Consumer then failing
>>> since the attach doesnt contain the needed information and leads to
>>> Dispatch detaching it with the error (though it again doesnt actually
>>> indicate its refusing the link during the attach response, as it
>>> probably should have in this case).
>>>
>>> Making the client detect the current failure and having it throw an
>>> aexception from createTemporaryQueue is simple enough.
>>>
>>> Hacking the client to use a dynamic recieving link instead, an address
>>> was returned by Dispatch in the attach response as expected, however a
>>> consumer on the resulting TemporaryQueue object using this address
>>> still didnt get the message I sent to the same place. If I also gave
>>> some credit on the link backing the TemporaryQeueue object itself then
>>> that link gets sent the message by Dispatch, though this of no use for
>>> the JMS client.
>>>
>>> Needs some more investigation, and I'll need to discuss with some
>>> folks more familiar with Dispatch.
>>>
>>> Robbie
>>>
>>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com> wrote:
>>>
>>>> Hello Robbie,
>>>>
>>>>
>>>> I replaced the "createQueue" with "createTemporaryQueue" for the reply
>>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS Client.
>>>>
>>>>
>>>> PS: As Rabih stated before, we are using the same connection and same
>>>> session to create the JMSProducer for the request and the JMSConsumer for
>>>> the reply.
>>>>
>>>>
>>>> Exception
>>>> -------------------
>>>> javax.jms.IllegalStateException: The MessageConsumer was closed due to
>>>> an unrecoverable error.
>>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
>>>> eConsumer.java:330)
>>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
>>>> sumer.java:196)
>>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>>>> ssorImpl.java:62)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>>> thodAccessorImpl.java:43)
>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
>>>> Caused by: javax.jms.JMSException: No route to the destination node
>>>> [condition = qd:no-route-to-dest]
>>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>>>> tion(AmqpSupport.java:150)
>>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>>>> tion(AmqpSupport.java:105)
>>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
>>>> elyClosed(AmqpAbstractResource.java:147)
>>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
>>>> ssRemoteClose(AmqpAbstractResource.java:251)
>>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
>>>> s(AmqpProvider.java:795)
>>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
>>>> mqpProvider.java:90)
>>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
>>>> ovider.java:699)
>>>> at java.util.concurrent.Executors$RunnableAdapter.call(
>>>> Executors.java:511)
>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>>> Executor.java:1142)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>>> lExecutor.java:617)
>>>> at java.lang.Thread.run(Thread.java:745)
>>>>
>>>>
>>>> -------------------
>>>> Dispatch Router (PN_TRACE_FRM=1)
>>>> -------------------
>>>>
>>>> [832220]: <- SASL
>>>> [832220]: -> SASL
>>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
>>>> MBOL[:ANONYMOUS]]
>>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
>>>> initial-response=b"", hostname="host-name"]
>>>> [832220]:0 -> @sasl-outcome(68) [code=0]
>>>> [832220]: <- AMQP
>>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-a334-44c3-954a-2dd910161411:1",
>>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
>>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
>>>> L[:"sole-connection-for-container"], properties={:product="QpidJMS",
>>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
>>>> Corporation, OS: Windows 7, 6.1, amd64"}]
>>>> [832220]: -> AMQP
>>>> [832220]:0 -> @open(16) [container-id="router.10200",
>>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
>>>> offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router",
>>>> :version="0.7.0"}]
>>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>>>> outgoing-window=2147483647, handle-max=65535]
>>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
>>>> incoming-window=61, outgoing-window=2147483647]
>>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>>>> outgoing-window=2147483647, handle-max=65535]
>>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
>>>> incoming-window=61, outgoing-window=2147483647]
>>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
>>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
>>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
>>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]],
>>>> target=@target(41) [address="$management", durable=0,
>>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
>>>> initial-delivery-count=0]
>>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
>>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
>>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list",
>>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
>>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]],
>>>> initial-delivery-count=0, max-message-size=0]
>>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
>>>> link-credit=250, drain=false]
>>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
>>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
>>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [],
>>>> target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0,
>>>> dynamic=true, dynamic-node-properties={:"lif
>>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"temporary-queue"]],
>>>> incomplete-unsettled=false, initial-delivery-count=0]
>>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
>>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0, role=true,
>>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
>>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
>>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
>>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []},
>>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], initial-delivery-count=0,
>>>> max-message-size=0]
>>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
>>>> link-credit=250, drain=false]
>>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
>>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=true,
>>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [durable=0,
>>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
>>>> default-outcome=@modified(39) [delivery-failed=true],
>>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
>>>> :"amqp:released:list", :"amqp:modified:list"],
>>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41) []]
>>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
>>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=false,
>>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
>>>> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0,
>>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
>>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
>>>> [condition=:"qd:no-route-to-dest", description="No route to the
>>>> destination node"]]
>>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
>>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"0",
>>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
>>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
>>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
>>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
>>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
>>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
>>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
>>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
>>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
>>>> x04addr\xa1\x0dbrokerMachine"
>>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
>>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1,
>>>> link-credit=250, drain=false]
>>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
>>>> settled=true, state=@accepted(36) []]
>>>> [832220]:0 <- @close(24) []
>>>> [832220]: <- EOS
>>>> [832220]:0 -> @close(24) []
>>>> [832220]: -> EOS
>>>> Closed x.x.x.x:8961
>>>> Unexpected poll events: 0020 on x.x.x.x:8961
>>>> Unexpected poll events: 0020 on x.x.x.x:8961
>>>>
>>>> ------------------
>>>> JMS Client (PN_TRACE_FRM=1)
>>>> ------------------
>>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-4a22-9b22-69d27a017a83:1',
>>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
>>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
>>>> offeredCapabilities=null, desiredCapabilities=[sole-connection-for-container],
>>>> properties={product=QpidJMS, version=0.11.1, platform=JVM: 1.8.0_111,
>>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
>>>> [1244186219:0] <- Open{ containerId='router.10200', hostname='null',
>>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
>>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[ANONYMOUS-RELAY],
>>>> desiredCapabilities=null, properties={product=qpid-dispatch-router,
>>>> version=0.7.0}}
>>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
>>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
>>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
>>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
>>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
>>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
>>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>>> source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1',
>>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>>>> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list],
>>>> capabilities=null}, target=Target{address='$management', durable=NONE,
>>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
>>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
>>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>>> source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1',
>>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>>>> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list],
>>>> capabilities=null}, target=Target{address='$management', durable=NONE,
>>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
>>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0,
>>>> linkCredit=250, available=null, drain=false, echo=false, properties=null}
>>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
>>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>>> distributionMode=null, filter=null, defaultOutcome=null, outcomes=null,
>>>> capabilities=null}, target=Target{address='null', durable=NONE,
>>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>>>> capabilities=[temporary-queue]}, unsettled=null,
>>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
>>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>>> distributionMode=null, filter=null, defaultOutcome=null, outcomes=null,
>>>> capabilities=null}, target=Target{address='null', durable=NONE,
>>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>>>> capabilities=[temporary-queue]}, unsettled=null,
>>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
>>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0,
>>>> linkCredit=250, available=null, drain=false, echo=false, properties=null}
>>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
>>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>>> source=Source{address='null', durable=NONE, expiryPolicy=LINK_DETACH,
>>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>>> distributionMode=null, filter=null, defaultOutcome=Modified{deliveryFailed=true,
>>>> undeliverableHere=null, messageAnnotations=null},
>>>> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list,
>>>> amqp:modified:list], capabilities=[temporary-queue]},
>>>> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>>> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
>>>> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
>>>> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
>>>> properties=null}
>>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
>>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>>> distributionMode=null, filter=null, defaultOutcome=null, outcomes=null,
>>>> capabilities=null}, target=Target{address='null', durable=NONE,
>>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
>>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:1] <- Detach{handle=1, closed=true,
>>>> error=Error{condition=qd:no-route-to-dest, description='No route to the
>>>> destination node', info=null}}
>>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
>>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
>>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null, state=null,
>>>> resume=false, aborted=false, batchable=false} (312)
>>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
>>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
>>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@
>>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
>>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
>>>> apache.qpid.dispatch.connector\xa1\x09operation\
>>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
>>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
>>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
>>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
>>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=1,
>>>> linkCredit=250, available=null, drain=false, echo=false, properties=null}
>>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
>>>> settled=true, state=Accepted{}, batchable=false}
>>>> [1244186219:0] -> Close{error=null}
>>>> [1244186219:0] <- Close{error=null}
>>>>
>>>> Regards,
>>>>
>>>> Adel
>>>>
>>>> ________________________________
>>>> From: Robbie Gemmell <ro...@gmail.com>
>>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
>>>> To: users@qpid.apache.org
>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>>>
>>>> That looks fine at first glance. Its possible there is an issue in
>>>> there needing looked it. I am travelling this week so may not get to
>>>> look until afterwards, but will try to give things a look at. If you
>>>> could give more detail on the exception and maybe a protocol trace
>>>> that might be useful.
>>>>
>>>> Robbie
>>>>
>>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
>>>>
>>>>> Hello Robbie,
>>>>>
>>>>> Thanks for you for your answer.
>>>>> I will try the solutions you proposed.
>>>>>
>>>>> I need just need one clarification. Concerning the Jms, I already tried
>>>>> to
>>>>> use a temporary queue but it didn't work. May be i am using it wrong.
>>>>> Here
>>>>> is what i did:
>>>>>
>>>>> ...
>>>>> Session session = connection.createSession(false,
>>>>> Session.AUTO_ACKNOWLEDGE);
>>>>> Queue queue = session.createQueue("$management");
>>>>> MessageProducer producer = session.createProducer(queue);
>>>>>
>>>>> Queue tempDest = session.createTemporaryQueue();
>>>>> MessageConsumer responseConsumer = session.createConsumer(tempDest);
>>>>> connection.start();
>>>>>
>>>>> ObjectMessage objectMessage = session.createObjectMessage();
>>>>> objectMessage.setJMSReplyTo(tempDest);
>>>>> //fill the rest of the parameters ...
>>>>> producer.send(objectMessage);
>>>>> ObjectMessage replyMessage = (ObjectMessage)
>>>>> responseConsumer.receive(1000);
>>>>> ...
>>>>>
>>>>> I was getting an exception on the .receive() from the dispatch router
>>>>> saying that the reply-to address is bad...
>>>>> Should i create the temporary queue and the consumer from a different
>>>>> session then the producer?
>>>>>
>>>>> Best regards,
>>>>> Rabih
>>>>>
>>>>>
>>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
>>>>> robbie.gemmell@gmail.com>
>>>>> wrote:
>>>>>
>>>>> The session.createTemporaryQueue(); method is how JMS creates
>>>>>> temporary destinations for use in reply-to scenarios. The dispatch
>>>>>> tools will be doing essentially the same thing under the covers for
>>>>>> theirs.
>>>>>>
>>>>>> Both work by creating a 'dynamic' link attachment, with the server
>>>>>> returning an address for the dynamic attach to the client. One key
>>>>>> difference is with JMS you create the temporary destination (for which
>>>>>> the client uses a dynamic sender link to create), then separately
>>>>>> create a receiver using it (and in turn the address associated with
>>>>>> it), whereas non-JMS client/tools will typically just create a single
>>>>>> dynamic receiver link and use its address for the reply-to.
>>>>>>
>>>>>> For proton-j, there aren't any examples for this, but you you
>>>>>> essentially would change the link opening to not specify an address,
>>>>>> and instead set the source(for a receiver) or target (for a sender) to
>>>>>> be 'dynamic'. You would then inspect the remoteSource or remoteTarget
>>>>>> once the link had been reemotely attached, and get its
>>>>>> (server-generated) address, then use this as your reply-to.
>>>>>>
>>>>>> Robbie
>>>>>>
>>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like you
>>>>>>> suggested, it worked.
>>>>>>> But I cheated a little to make it work because I did not find a way in
>>>>>>>
>>>>>> JMS
>>>>>>
>>>>>>> to create a local queue. So I created a queue on the qpid-dispatch and
>>>>>>>
>>>>>> read
>>>>>>
>>>>>>> the result from it. You can check the attached code.
>>>>>>>
>>>>>>> Is there any way using qpid-jms to create a local queue on the client
>>>>>>>
>>>>>> side
>>>>>>
>>>>>>> to serve as a reply to address?
>>>>>>>
>>>>>>> For the proton-j test, I have the same question as above. I saw that
>>>>>>> it
>>>>>>>
>>>>>> can
>>>>>>
>>>>>>> be done with the C++ API. Are there any examples for proton-j or
>>>>>>>
>>>>>> something
>>>>>>
>>>>>>> that can help me?
>>>>>>>
>>>>>>> I saw may be in proton we don't need a local queue, may be we can get
>>>>>>> the
>>>>>>> address of the consumer directly and pass it in reply-to field. Is it
>>>>>>> correct?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rabih
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
>>>>>>> rob.j.godfrey@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>
>>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
>>>>>>>>>> To: users@qpid.apache.org
>>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
>>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>>>>>>>>>
>>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you told
>>>>>>>>>>>>
>>>>>>>>>>> me
>>>>>>
>>>>>>> Robbie and it worked.
>>>>>>>>>>>>
>>>>>>>>>>>> But like the proton-j case, the connector is not being created on
>>>>>>>>>>>> the
>>>>>>>>>>>> Qpid-dispatch side.
>>>>>>>>>>>> I attached the amqp communication into this mail.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The last frame in that file is incomplete (the previous error
>>>>>>>>>>>
>>>>>>>>>> regarding the
>>>>>>>>>
>>>>>>>>>> map body may or may not be a wireshark issue),but that last frame
>>>>>>>>>>>
>>>>>>>>>> is
>>>>>>
>>>>>>> likely
>>>>>>>>>
>>>>>>>>>> the response which would indicate the success or otherwise of the
>>>>>>>>>>>
>>>>>>>>>> frame. Is
>>>>>>>>>
>>>>>>>>>> there anything logged by the router?
>>>>>>>>>>>
>>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is simpler
>>>>>>>>>>> for
>>>>>>>>>>>
>>>>>>>>>> this
>>>>>>>>>
>>>>>>>>>> sort of thing in my view.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> As Gordon suggests, the proton trace logs might be more helpful.
>>>>>>>>>> You
>>>>>>>>>> can also do that with proton-j, and this the JMS client too since
>>>>>>>>>> it
>>>>>>>>>> uses proton-j.
>>>>>>>>>>
>>>>>>>>>> One key difference from the qdmanage case is you are not setting a
>>>>>>>>>> reply-to value or correlation-id to use along with it. I don't know
>>>>>>>>>>
>>>>>>>>> if
>>>>>>
>>>>>>> the router cares about not being able to send a response or not
>>>>>>>>>> though, but it might.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You could add the following to your dispatch router conf file
>>>>>>>>> (qdrouterd.conf) and restart the router (This will enable trace
>>>>>>>>>
>>>>>>>> logging)
>>>>>>
>>>>>>>
>>>>>>>>> log {
>>>>>>>>> module: DEFAULT
>>>>>>>>> enable: trace+
>>>>>>>>> output: /path/to/log/qdrouterd.log
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> When you run your management request, you will see proton frame
>>>>>>>>> trace
>>>>>>>>> and
>>>>>>>>> you will see additional logging out of the dispatch Python agent -
>>>>>>>>> something like the following -
>>>>>>>>>
>>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>>>>>>>>> Message(address=None,
>>>>>>>>> properties={'operation': 'CREATE', 'type':
>>>>>>>>> 'org.apache.qpid.dispatch.connector',
>>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
>>>>>>>>>
>>>>>>>> 'rabih.connector'},
>>>>>>
>>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>>>>>>>>> correlation_id=1L)
>>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>>>>>>>>> broker-machine:5673 proto=any, role=route-container
>>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
>>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector,
>>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>>>>>>>>> name=rabih.connector, port=5673, role=route-container,
>>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
>>>>>>>>> verifyHostName=True)
>>>>>>>>>
>>>>>>>>> The Python management agent will not process your request if there
>>>>>>>>> is
>>>>>>>>>
>>>>>>>> no
>>>>>>
>>>>>>> reply_to as seen here -
>>>>>>>>>
>>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
>>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Can I ask why the agent doesn't process the request? Just because
>>>>>>>> there
>>>>>>>> is
>>>>>>>> a reply-to doesn't mean that the sender will be around to actually
>>>>>>>> hear
>>>>>>>> the
>>>>>>>> reply, so it seems a bit arbitrary to say that because we *know* the
>>>>>>>> sender
>>>>>>>> won't learn of the outcome that we won't do anything... The spec
>>>>>>>> draft
>>>>>>>> doesn't currently say anything about this (obviously it should do),
>>>>>>>> but
>>>>>>>>
>>>>>>> my
>>>>>>
>>>>>>> expectation would certainly be that a request would be processed even
>>>>>>>> if
>>>>>>>> the replyTo address was not present (or ended up not routing
>>>>>>>> anywhere).
>>>>>>>> This is also how the Qpid Broker for Java implements this case.
>>>>>>>>
>>>>>>>> -- Rob
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Robbie
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>> ---------
>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Adel Boutros <Ad...@live.com>.
Thank you Ganesh.
In that case, I will stick to using qdstat for the moment.
Regards,
Adel
________________________________
From: Ganesh Murthy <gm...@redhat.com>
Sent: Wednesday, February 22, 2017 5:12:23 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
----- Original Message -----
> From: "Adel Boutros" <Ad...@live.com>
> To: users@qpid.apache.org
> Sent: Wednesday, February 22, 2017 10:58:42 AM
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> Hello,
>
>
> One more issue: I am trying to replicate a "qdstat -a" to get the statistics
> of the addresses.
>
> It seems the 'name' and 'identity' fields returned are always prefixed by
> some weird combinations "L" or "M0" or "L$", etc. Is this expected?
>
The "L" or "M" etc are used by qdstat to display some additional information in its output.
If you look in the qdstat python program, you will see the following -
def _addr_class(self, addr):
if not addr:
return ""
if addr[0] == 'M' : return "mobile"
if addr[0] == 'R' : return "router"
if addr[0] == 'A' : return "area"
if addr[0] == 'L' : return "local"
if addr[0] == 'T' : return "topo"
if addr[0] == 'C' : return "link-in"
if addr[0] == 'D' : return "link-out"
return "unknown: %s" % addr[0]
But, I agree that the addresses themselves should not have these prefixes.
There is a JIRA for this already -
https://issues.apache.org/jira/browse/DISPATCH-450
I am not sure we can get to this before the 0.8 release but we will try.
In the meantime, you could use the same logic that qdstat uses.
Thanks.
>
> Output
>
> --------------
>
> attributeNames: [name, identity, type, key, distribution, inProcess,
> subscriberCount, remoteCount, containerCount, remoteHostRouters,
> deliveriesIngress, deliveriesEgress, deliveriesTransit,
> deliveriesToContainer, deliveriesFromContainer, transitOutstanding,
> trackedDeliveries]
>
> results: [[Lqdhello, Lqdhello, org.apache.qpid.dispatch.router.address,
> Lqdhello, flood, 1, 0, 0, 0, [], 0, 0, 0, 0, 1379, null, 0], [Lqdrouter,
> Lqdrouter, org.apache.qpid.dispatch.router.address, Lqdrouter, flood, 1, 0,
> 0, 0, [], 0, 0, 0, 0, 0, null, 0], [Lqdrouter.ma, Lqdrouter.ma,
> org.apache.qpid.dispatch.router.address, Lqdrouter.ma, multicast, 1, 0, 0,
> 0, [], 0, 0, 0, 0, 0, null, 0], [Tqdrouter, Tqdrouter,
> org.apache.qpid.dispatch.router.address, Tqdrouter, flood, 1, 0, 0, 0, [],
> 0, 0, 0, 0, 46, null, 0], [Tqdrouter.ma, Tqdrouter.ma,
> org.apache.qpid.dispatch.router.address, Tqdrouter.ma, multicast, 1, 0, 0,
> 0, [], 0, 0, 0, 0, 2, null, 0], [M0$management, M0$management,
> org.apache.qpid.dispatch.router.address, M0$management, closest, 1, 0, 0, 0,
> [], 7, 0, 0, 7, 0, null, 0], [L$management, L$management,
> org.apache.qpid.dispatch.router.address, L$management, closest, 1, 0, 0, 0,
> [], 0, 0, 0, 0, 0, null, 0], [L$_management_internal,
> L$_management_internal, org.apache.qpid.dispatch.router.address,
> L$_management_internal, closest, 1, 0, 0, 0, [], 0, 0, 0, 0, 0, null, 0],
> [L$displayname, L$displayname, org.apache.qpid.dispatch.router.address,
> L$displayname, closest, 1, 0, 0, 0, [], 0, 0, 0, 0, 0, null, 0],
> [M0$management_reply_queue, M0$management_reply_queue,
> org.apache.qpid.dispatch.router.address, M0$management_reply_queue,
> balanced, 0, 1, 0, 0, [], 0, 0, 0, 0, 0, null, 0]]
>
>
>
> Code
>
> ---------------
>
> ConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://green-lx-slave1:10501");
> Connection managementConnection = connectionFactory.createConnection();
> Session managementSession = managementConnection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> Queue managementQueue = managementSession.createQueue("$management");
> MessageProducer managementProducer =
> managementSession.createProducer(managementQueue);
> Queue replyToQueue =
> managementSession.createQueue("$management_reply_queue");
> MessageConsumer managementConsumer =
> managementSession.createConsumer(replyToQueue);
> managementConnection.start();
>
> // An object message should be used because the Map and List content must be
> encoded with AMQP encoding.
> ObjectMessage objectMessage = managementSession.createObjectMessage();
>
> // Setting management message header properties
> // JMS_AMQP_TYPED_ENCODING is a temporary solution that is used by qpid-jms
> to encode the message content with AMQP encoding before sending it.
> objectMessage.setBooleanProperty("JMS_AMQP_TYPED_ENCODING", true);
> objectMessage.setStringProperty("operation", "QUERY");
> objectMessage.setStringProperty("type",
> "org.apache.qpid.dispatch.router.address");
> objectMessage.setStringProperty("name", "self");
> objectMessage.setJMSReplyTo(replyToQueue);
>
> managementProducer.send(objectMessage);
>
> ObjectMessage replyMessage = (ObjectMessage) managementConsumer.receive();
>
> Map<String, Object> resultObject = (Map<String, Object>)
> replyMessage.getObject();
> for (Map.Entry<String, Object> entry : resultObject.entrySet()) {
> System.out.println(entry.getKey() + ": " + entry.getValue());
> }
>
> managementConnection.close();
>
> Regards,
>
> Adel
> ________________________________
> From: Adel Boutros <Ad...@live.com>
> Sent: Wednesday, February 22, 2017 12:33:32 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> Hello guys,
>
>
> My basic JMS API is almost ready. I will share it with you soon to have your
> feedback.
>
>
> However, I tried one last thing by getting a random queue name and using it
> as management reply queue to allow multiple configuration sessions
> simultaneously but it didn't work.
>
>
> //This doesn't work and crashes the dispatch router
>
> TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
> replyToQueue = managementSession.createQueue(temporaryQueue.getQueueName());
> managementConsumer = managementSession.createConsumer(replyToQueue);
>
> //This is the only thing working
> replyToQueue = managementSession.createQueue("HARD_CODED_REPLY_QUEUE");
> managementConsumer = managementSession.createConsumer(replyToQueue);
>
>
> Can I have your input on the above?
>
> Regards,
> Adel
>
>
> ________________________________
> From: Rob Godfrey <ro...@gmail.com>
> Sent: Wednesday, February 15, 2017 4:46:59 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> On 15 February 2017 at 16:07, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
> > On 15 February 2017 at 14:15, Adel Boutros <Ad...@live.com> wrote:
> > > Hello guys,
> > >
> > >
> > > Based on the discussion, we are currently writing a Java API based on
> > JMS to configure the dispatch router. I have so far managed to do the
> > following:
> > >
> > > * Create, Read, Delete addresses
> > >
> > > * Create, Read, Delete connectors
> > >
> > >
> > > Config:
> > >
> > > Dispatch Router 0.7.0
> > >
> > > JMS 0.11.1
> > >
> > >
> > > And I have noticed some problems and differences:
> > >
> > >
> > > 1) It seems some calls return ObjectMessage and some TextMessage (This
> > is on the side of the consumer in the replyTo)
> > >
> > > For example, creating twice the same queue will fail but the second call
> > will return a JmsTextMessage with an empty body and status code 400
> > >
> >
> > The client treats messages with an amqp-value sectioning containing
> > null/nothing as a TextMessage with null value if they arent annotated
> > to say otherwise, I'd guess thats where that comes from.
> >
> > >
> > > 2) Returned statusCode differs between Connector and Address
> > >
> > > Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
> > >
> > >
> > > * Connector operations return java.lang.Long
> > > * Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
> > >
> >
> > The router is presumably sending different values back for the
> > different operations here, a long and a uint. The router should
> > perhaps be consistent, and the client should perhaps not be returning
> > the uint object either way.
> >
> > The last draft of the management spec seems to say the status code
> > should be 'integer', im not clear if it means int (not uint)
> > specifically, or just any integral type value.
> >
> >
> The specification should definitely say which type should - so we'll fix
> that in the next draft. I'd suggest we should int (in AMQP terms) leading
> to a java.lang.Integer type in the property you see through Java.
>
> -- Rob
>
>
>
> > >
> > > 3) Create connector twice makes dispatch router crash. I don't have the
> > issue when creating addresses.
> > > On the second create call, JMS client receives a normal reply
> > containing a statusCode of an exception. After I close the connection to
> > the dispatch router via JMS (connection.close), I have the below crash
> > >
> > > (gdb) where
> > > #0 0x00007f27194448a5 in raise () from /lib64/libc.so.6
> > > #1 0x00007f2719446085 in abort () from /lib64/libc.so.6
> > > #2 0x00007f27194827b7 in __libc_message () from /lib64/libc.so.6
> > > #3 0x00007f27194880e6 in malloc_printerr () from /lib64/libc.so.6
> > > #4 0x00007f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf
> > expression opcode 0xf3
> > > ) at /qpid-dispatch-0.7.0/src/hash.c:320
> > > #5 0x00007f271a42247d in qdr_route_check_id_for_deletion_CT
> > (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
> > > ) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
> > > #6 0x00007f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30,
> > action=Unhandled dwarf expression opcode 0xf3
> > > ) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
> > > #7 0x00007f271a423f30 in router_core_thread (arg=0x13d2d30) at
> > /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
> > > #8 0x00007f2719f8c851 in start_thread () from /lib64/libpthread.so.0
> > > #9 0x00007f27194fa90d in clone () from /lib64/libc.so.6
> > >
> > >
> > > Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE:
> > org.apache.qpid.dispatch.connector: Duplicate value 'connector/
> > 127.0.0.1:5915:dispatch_management_connector_test' for unique attribute
> > 'identity'
> > > *** glibc detected *** /Dispatch/sbin/qdrouterd: double free or
> > corruption (fasttop): 0x00007f2708033f10 ***
> > > ======= Backtrace: =========
> > > /lib64/libc.so.6(+0x760e6)[0x7f27194880e6]
> > > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> > .so(qd_hash_remove_by_handle+0x29)[0x7f271a40f109]
> > > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> > .so(+0x3547d)[0x7f271a42247d]
> > > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> > .so(+0x318d3)[0x7f271a41e8d3]
> > > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> > .so(router_core_thread+0x230)[0x7f271a423f30]
> > > /lib64/libpthread.so.0(+0x7851)[0x7f2719f8c851]
> > > /lib64/libc.so.6(clone+0x6d)[0x7f27194fa90d]
> > > ======= Memory map: ========
> > > 00400000-00403000 r-xp 00000000 fd:01 7735642
> > /Dispatch/sbin/qdrouterd
> > > 00603000-00604000 rw-p 00003000 fd:01 7735642
> > /Dispatch/sbin/qdrouterd
> > > 01113000-01458000 rw-p 00000000 00:00 0
> > [heap]
> > > 7f26f8000000-7f26f805c000 rw-p 00000000 00:00 0
> > > 7f26f805c000-7f26fc000000 ---p 00000000 00:00 0
> > > 7f26fc000000-7f26fc043000 rw-p 00000000 00:00 0
> > > 7f26fc043000-7f2700000000 ---p 00000000 00:00 0
> > > 7f2700000000-7f2700085000 rw-p 00000000 00:00 0
> > > 7f2700085000-7f2704000000 ---p 00000000 00:00 0
> > > 7f27073e9000-7f27073ff000 r-xp 00000000 fd:00 524293
> > /lib64/libgcc_s-4.4.7-20120601.so.1
> > > 7f27073ff000-7f27075fe000 ---p 00016000 fd:00 524293
> > /lib64/libgcc_s-4.4.7-20120601.so.1
> > > 7f27075fe000-7f27075ff000 rw-p 00015000 fd:00 524293
> > /lib64/libgcc_s-4.4.7-20120601.so.1
> > > 7f27075ff000-7f2707600000 ---p 00000000 00:00 0
> > > 7f2707600000-7f2708000000 rw-p 00000000 00:00 0
> > > 7f2708000000-7f270805a000 rw-p 00000000 00:00 0
> > > 7f270805a000-7f270c000000 ---p 00000000 00:00 0
> > > 7f270c04a000-7f270c04f000 r-xp 00000000 fd:00 524322
> > /lib64/libnss_dns-2.12.so
> > > 7f270c04f000-7f270c24e000 ---p 00005000 fd:00 524322
> > /lib64/libnss_dns-2.12.so
> > > 7f270c24e000-7f270c24f000 r--p 00004000 fd:00 524322
> > /lib64/libnss_dns-2.12.so
> > > 7f270c24f000-7f270c250000 rw-p 00005000 fd:00 524322
> > /lib64/libnss_dns-2.12.so
> > > 7f270c250000-7f270c251000 ---p 00000000 00:00 0
> > > 7f270c251000-7f270cc51000 rw-p 00000000 00:00 0
> > > 7f270cc51000-7f270cc52000 ---p 00000000 00:00 0
> > > 7f270cc52000-7f270d652000 rw-p 00000000 00:00 0
> > > 7f270d652000-7f270d65e000 r-xp 00000000 fd:00 524324
> > /lib64/libnss_files-2.12.so
> > > 7f270d65e000-7f270d85e000 ---p 0000c000 fd:00 524324
> > /lib64/libnss_files-2.12.so
> > > 7f270d85e000-7f270d85f000 r--p 0000c000 fd:00 524324
> > /lib64/libnss_files-2.12.so
> > > 7f270d85f000-7f270d860000 rw-p 0000d000 fd:00 524324
> > /lib64/libnss_files-2.12.so
> > > 7f270d86a000-7f270d86b000 ---p 00000000 00:00 0
> > > 7f270d86b000-7f270e3ac000 rw-p 00000000 00:00 0
> > > 7f270e3ac000-7f270e3b1000 r-xp 00000000 00:16 4090944
> > /python278/lib/python2.7/lib-dynload/select.so
> > > 7f270e3b1000-7f270e5b0000 ---p 00005000 00:16 4090944
> > /python278/lib/python2.7/lib-dynload/select.so
> > > 7f270e5b0000-7f270e5b2000 rw-p 00004000 00:16 4090944
> > /python278/lib/python2.7/lib-dynload/select.so
> > > 7f270e5b2000-7f270e5b6000 r-xp 00000000 00:16 5568743
> > /python278/lib/python2.7/lib-dynload/_lsprof.so
> > > 7f270e5b6000-7f270e7b5000 ---p 00004000 00:16 5568743
> > /python278/lib/python2.7/lib-dynload/_lsprof.so
> > > 7f270e7b5000-7f270e7b6000 rw-p 00003000 00:16 5568743
> > /python278/lib/python2.7/lib-dynload/_lsprof.so
> > > 7f270e7b6000-7f270e8b7000 rw-p 00000000 00:00 0
> > > 7f270e8b7000-7f270e8bc000 r-xp 00000000 00:16 6394000
> > /python278/lib/python2.7/lib-dynload/strop.so
> > > 7f270e8bc000-7f270eabb000 ---p 00005000 00:16 6394000
> > /python278/lib/python2.7/lib-dynload/strop.so
> > > 7f270eabb000-7f270eabd000 rw-p 00004000 00:16 6394000
> > /python278/lib/python2.7/lib-dynload/strop.so
> > > 7f270eabd000-7f270eafd000 rw-p 00000000 00:00 0
> > > 7f270eafd000-7f270eb00000 r-xp 00000000 00:16 5568749
> > /python278/lib/python2.7/lib-dynload/fcntl.so
> > > 7f270eb00000-7f270ecff000 ---p 00003000 00:16 5568749
> > /python278/lib/python2.7/lib-dynload/fcntl.so
> > > 7f270ecff000-7f270ed01000 rw-p 00002000 00:16 5568749
> > /python278/lib/python2.7/lib-dynload/fcntl.so
> > > 7f270ed01000-7f270ed04000 r-xp 00000000 00:16 5568739
> > /python278/lib/python2.7/lib-dynload/_random.so
> > > 7f270ed04000-7f270ef03000 ---p 00003000 00:16 5568739
> > /python278/lib/python2.7/lib-dynload/_random.so
> > > 7f270ef03000-7f270ef04000 rw-p 00002000 00:16 5568739
> > /python278/lib/python2.7/lib-dynload/_random.so
> > > 4272 Aborted (core dumped)
> > >
> > >
> > > Regards,
> > > Adel
> > >
> > >
> > > ________________________________
> > > From: Rob Godfrey <ro...@gmail.com>
> > > Sent: Monday, February 6, 2017 7:09 PM
> > > To: users@qpid.apache.org
> > > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> > >
> > > On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
> > > wrote:
> > >
> > >> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com>
> > wrote:
> > >> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
> > >> >
> > >> >> It seems odd that the client creates a _sender_ to the temporary
> > queue
> > >> >> that it will never send messages _to_ but will receive messages
> > _from_.
> > >> >>
> > >> >>
> > >> > This is because JMS semantics require the temporary node to have a
> > >> lifetime
> > >> > scoped to the session (not a link), so the JMS client has to create a
> > >> > synthetic link which it uses simply to manage the lifetime of the
> > dynamic
> > >> > node. In order to not cause unintentional assigning of messages to a
> > >> link
> > >> > that will never actually be used for consumption, a sending link is
> > used.
> > >> > Note that in general JMS would expect that you should be able to send
> > to
> > >> a
> > >> > temporary queue created in this way (since the point of temporary
> > queues
> > >> is
> > >> > to use as a reply to)
> > >> >
> > >>
> > >> Not really important here, but the lifetime is scoped to the
> > >> Connection, not Session (agghhh JMS... :P)
> > >>
> > >
> > > That's what I thought I was typing... obviously my fingers were not
> > > cooperating with my brain at that point :-)
> > >
> > > -- Rob
> > >
> > >
> > >>
> > >> >
> > >> >> Anyway, when the client creates a receiver with a dynamic source
> > (and no
> > >> >> dynamic-node-properties), the router will accept the link and assign
> > a
> > >> >> temporary address as the source. This is only useful in this use
> > case
> > >> if
> > >> >> the broker has a way of knowing that the temporary address is
> > reachable
> > >> via
> > >> >> the router network.
> > >> >>
> > >> >> There is a way to route dynamic termini to a broker. If an
> > >> >> x-opt-qd.address property is included in the dynamic-node-properties,
> > >> this
> > >> >> address will be used to route the attach to the broker. I've never
> > >> tested
> > >> >> this with a dynamic target in a sender. It might not work.
> > >> >
> > >> >
> > >> > And this really isn't something you'd be expecting a generic client
> > (like
> > >> > the JMS client) to know :-)
> > >> >
> > >> > -- Rob
> > >> >
> > >> >
> > >> >>
> > >> >>
> > >> >> -Ted
> > >> >>
> > >> >>
> > >> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
> > >> >>
> > >> >>> I've had a look at this. It would seem that Dispatch doesn't like
> > what
> > >> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
> > >> >>> very nice way, and the client then doesnt notice that things have
> > gone
> > >> >>> south in a somewhat unexpected way.
> > >> >>>
> > >> >>> The client opens a sending link with 'dynamic' target in order to
> > >> >>> create a dynamic node for use as a TemporaryQueue
> > address/destination
> > >> >>> object, which specific consumers/producers are then created against
> > by
> > >> >>> the application. Dispatch doesn't seem to like that but erroneously
> > >> >>> attaches the link 'successfully', though doesnt set a target address
> > >> >>> as is expected. The client then doesnt notice this happened (its
> > >> >>> checking for the link being refused, which it wasn't), allowing the
> > >> >>> application to proceed as far as creating consumers/procuers using
> > the
> > >> >>> TemporaryQueue object, with creation of the e.g Consumer then
> > failing
> > >> >>> since the attach doesnt contain the needed information and leads to
> > >> >>> Dispatch detaching it with the error (though it again doesnt
> > actually
> > >> >>> indicate its refusing the link during the attach response, as it
> > >> >>> probably should have in this case).
> > >> >>>
> > >> >>> Making the client detect the current failure and having it throw an
> > >> >>> aexception from createTemporaryQueue is simple enough.
> > >> >>>
> > >> >>> Hacking the client to use a dynamic recieving link instead, an
> > address
> > >> >>> was returned by Dispatch in the attach response as expected,
> > however a
> > >> >>> consumer on the resulting TemporaryQueue object using this address
> > >> >>> still didnt get the message I sent to the same place. If I also gave
> > >> >>> some credit on the link backing the TemporaryQeueue object itself
> > then
> > >> >>> that link gets sent the message by Dispatch, though this of no use
> > for
> > >> >>> the JMS client.
> > >> >>>
> > >> >>> Needs some more investigation, and I'll need to discuss with some
> > >> >>> folks more familiar with Dispatch.
> > >> >>>
> > >> >>> Robbie
> > >> >>>
> > >> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
> > >> wrote:
> > >> >>>
> > >> >>>> Hello Robbie,
> > >> >>>>
> > >> >>>>
> > >> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the
> > reply
> > >> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS
> > Client.
> > >> >>>>
> > >> >>>>
> > >> >>>> PS: As Rabih stated before, we are using the same connection and
> > same
> > >> >>>> session to create the JMSProducer for the request and the
> > >> JMSConsumer for
> > >> >>>> the reply.
> > >> >>>>
> > >> >>>>
> > >> >>>> Exception
> > >> >>>> -------------------
> > >> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed
> > due
> > >> to
> > >> >>>> an unrecoverable error.
> > >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
> > >> >>>> eConsumer.java:330)
> > >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
> > >> >>>> sumer.java:196)
> > >> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
> > >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> > >> >>>> ssorImpl.java:62)
> > >> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> > >> >>>> thodAccessorImpl.java:43)
> > >> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
> > >> >>>> at com.intellij.rt.execution.application.AppMain.main(
> > >> AppMain.java:147)
> > >> >>>> Caused by: javax.jms.JMSException: No route to the destination node
> > >> >>>> [condition = qd:no-route-to-dest]
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> > >> >>>> tion(AmqpSupport.java:150)
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> > >> >>>> tion(AmqpSupport.java:105)
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
> > >> >>>> elyClosed(AmqpAbstractResource.java:147)
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
> > >> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
> > >> >>>> s(AmqpProvider.java:795)
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
> > >> >>>> mqpProvider.java:90)
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
> > >> >>>> ovider.java:699)
> > >> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
> > >> >>>> Executors.java:511)
> > >> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> > >> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> > >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> > >> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
> > >> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> > >> >>>> Executor.java:1142)
> > >> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> > >> >>>> lExecutor.java:617)
> > >> >>>> at java.lang.Thread.run(Thread.java:745)
> > >> >>>>
> > >> >>>>
> > >> >>>> -------------------
> > >> >>>> Dispatch Router (PN_TRACE_FRM=1)
> > >> >>>> -------------------
> > >> >>>>
> > >> >>>> [832220]: <- SASL
> > >> >>>> [832220]: -> SASL
> > >> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
> > >> >>>> MBOL[:ANONYMOUS]]
> > >> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
> > >> >>>> initial-response=b"", hostname="host-name"]
> > >> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
> > >> >>>> [832220]: <- AMQP
> > >> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
> > >> a334-44c3-954a-2dd910161411:1",
> > >> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
> > >> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
> > >> >>>> L[:"sole-connection-for-container"],
> > properties={:product="QpidJMS",
> > >> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
> > >> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
> > >> >>>> [832220]: -> AMQP
> > >> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
> > >> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> > >> >>>> offered-capabilities=:"ANONYMOUS-RELAY",
> > properties={:product="qpid-
> > >> dispatch-router",
> > >> >>>> :version="0.7.0"}]
> > >> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> > >> >>>> outgoing-window=2147483647, handle-max=65535]
> > >> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
> > >> >>>> incoming-window=61, outgoing-window=2147483647]
> > >> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> > >> >>>> outgoing-window=2147483647, handle-max=65535]
> > >> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
> > >> >>>> incoming-window=61, outgoing-window=2147483647]
> > >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
> > >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> > >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
> > source=@source(40)
> > >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
> > durable=0,
> > >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> > >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list",
> > :"amqp:rejected:list"]],
> > >> >>>> target=@target(41) [address="$management", durable=0,
> > >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> > >> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
> > >> >>>> initial-delivery-count=0]
> > >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
> > >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> > >> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> > >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
> > durable=0,
> > >> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:acc
> > epted:list",
> > >> >>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
> > >> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
> > >> queue]],
> > >> >>>> initial-delivery-count=0, max-message-size=0]
> > >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> > >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> > >> delivery-count=0,
> > >> >>>> link-credit=250, drain=false]
> > >> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
> > >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> > >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
> > source=@source(40)
> > >> [],
> > >> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
> > >> timeout=0,
> > >> >>>> dynamic=true, dynamic-node-properties={:"lif
> > >> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
> > >> temporary-queue"]],
> > >> >>>> incomplete-unsettled=false, initial-delivery-count=0]
> > >> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
> > >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> > >> role=true,
> > >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> > [durable=0,
> > >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> > >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
> > >> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43)
> > []},
> > >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
> > >> initial-delivery-count=0,
> > >> >>>> max-message-size=0]
> > >> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> > >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> > >> delivery-count=0,
> > >> >>>> link-credit=250, drain=false]
> > >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
> > >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
> > role=true,
> > >> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> > [durable=0,
> > >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> > >> >>>> default-outcome=@modified(39) [delivery-failed=true],
> > >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> > >> >>>> :"amqp:released:list", :"amqp:modified:list"],
> > >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41)
> > []]
> > >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
> > >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
> > role=false,
> > >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> > [durable=0,
> > >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> > timeout=0,
> > >> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
> > >> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
> > >> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
> > >> >>>> destination node"]]
> > >> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
> > >> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
> > >> delivery-tag=b"0",
> > >> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
> > >> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
> > >> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
> > >> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
> > >> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
> > >> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
> > >> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
> > >> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
> > >> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
> > >> >>>> x04addr\xa1\x0dbrokerMachine"
> > >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
> > >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> > >> delivery-count=1,
> > >> >>>> link-credit=250, drain=false]
> > >> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
> > >> >>>> settled=true, state=@accepted(36) []]
> > >> >>>> [832220]:0 <- @close(24) []
> > >> >>>> [832220]: <- EOS
> > >> >>>> [832220]:0 -> @close(24) []
> > >> >>>> [832220]: -> EOS
> > >> >>>> Closed x.x.x.x:8961
> > >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> > >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> > >> >>>>
> > >> >>>> ------------------
> > >> >>>> JMS Client (PN_TRACE_FRM=1)
> > >> >>>> ------------------
> > >> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
> > >> 4a22-9b22-69d27a017a83:1',
> > >> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
> > >> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
> > >> connection-for-container],
> > >> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM:
> > 1.8.0_111,
> > >> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
> > >> >>>> [1244186219:0] <- Open{ containerId='router.10200',
> > hostname='null',
> > >> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
> > >> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
> > >> ANONYMOUS-RELAY],
> > >> >>>> desiredCapabilities=null, properties={product=qpid-dispa
> > tch-router,
> > >> >>>> version=0.7.0}}
> > >> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> > >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> > >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
> > >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
> > >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
> > >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
> > handle=0,
> > >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> > >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> > >> 3293ffc57168:1:1:1',
> > >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> > >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> > >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> > >> amqp:rejected:list],
> > >> >>>> capabilities=null}, target=Target{address='$management',
> > >> durable=NONE,
> > >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> > >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> > >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> > >> maxMessageSize=null,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
> > >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
> > handle=0,
> > >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> > >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> > >> 3293ffc57168:1:1:1',
> > >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> > >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> > >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> > >> amqp:rejected:list],
> > >> >>>> capabilities=null}, target=Target{address='$management',
> > >> durable=NONE,
> > >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> > >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> > >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> > maxMessageSize=0,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
> > >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> > >> deliveryCount=0,
> > >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> > >> properties=null}
> > >> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
> > >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> > >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> > >> >>>> source=Source{address='null', durable=NONE,
> > expiryPolicy=SESSION_END,
> > >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> > >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> > >> outcomes=null,
> > >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> > >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> > >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> > >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> > >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> > >> maxMessageSize=null,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
> > >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> > >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> > >> >>>> source=Source{address='null', durable=NONE,
> > expiryPolicy=SESSION_END,
> > >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> > >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> > >> outcomes=null,
> > >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> > >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> > >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> > >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> > >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> > maxMessageSize=0,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
> > >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> > >> deliveryCount=0,
> > >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> > >> properties=null}
> > >> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
> > >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> > >> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> > >> >>>> source=Source{address='null', durable=NONE,
> > expiryPolicy=LINK_DETACH,
> > >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> > >> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
> > >> deliveryFailed=true,
> > >> >>>> undeliverableHere=null, messageAnnotations=null},
> > >> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list,
> > amqp:released:list,
> > >> >>>> amqp:modified:list], capabilities=[temporary-queue]},
> > >> >>>> target=Target{address='null', durable=NONE,
> > expiryPolicy=SESSION_END,
> > >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> > >> capabilities=null},
> > >> >>>> unsettled=null, incompleteUnsettled=false,
> > initialDeliveryCount=null,
> > >> >>>> maxMessageSize=null, offeredCapabilities=null,
> > >> desiredCapabilities=null,
> > >> >>>> properties=null}
> > >> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
> > >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> > >> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> > >> >>>> source=Source{address='null', durable=NONE,
> > expiryPolicy=SESSION_END,
> > >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> > >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> > >> outcomes=null,
> > >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> > >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> > >> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> > >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> > maxMessageSize=0,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
> > >> >>>> error=Error{condition=qd:no-route-to-dest, description='No route
> > to
> > >> the
> > >> >>>> destination node', info=null}}
> > >> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
> > >> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
> > >> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
> > >> state=null,
> > >> >>>> resume=false, aborted=false, batchable=false} (312)
> > >> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
> > >> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
> > >> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$man
> > agement@
> > >> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
> > >> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
> > >> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
> > >> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
> > >> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
> > >> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
> > >> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
> > >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> > >> deliveryCount=1,
> > >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> > >> properties=null}
> > >> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
> > >> >>>> settled=true, state=Accepted{}, batchable=false}
> > >> >>>> [1244186219:0] -> Close{error=null}
> > >> >>>> [1244186219:0] <- Close{error=null}
> > >> >>>>
> > >> >>>> Regards,
> > >> >>>>
> > >> >>>> Adel
> > >> >>>>
> > >> >>>> ________________________________
> > >> >>>> From: Robbie Gemmell <ro...@gmail.com>
> > >> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
> > >> >>>> To: users@qpid.apache.org
> > >> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> > >> >>>>
> > >> >>>> That looks fine at first glance. Its possible there is an issue in
> > >> >>>> there needing looked it. I am travelling this week so may not get
> > to
> > >> >>>> look until afterwards, but will try to give things a look at. If
> > you
> > >> >>>> could give more detail on the exception and maybe a protocol trace
> > >> >>>> that might be useful.
> > >> >>>>
> > >> >>>> Robbie
> > >> >>>>
> > >> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com>
> > wrote:
> > >> >>>>
> > >> >>>>> Hello Robbie,
> > >> >>>>>
> > >> >>>>> Thanks for you for your answer.
> > >> >>>>> I will try the solutions you proposed.
> > >> >>>>>
> > >> >>>>> I need just need one clarification. Concerning the Jms, I already
> > >> tried
> > >> >>>>> to
> > >> >>>>> use a temporary queue but it didn't work. May be i am using it
> > wrong.
> > >> >>>>> Here
> > >> >>>>> is what i did:
> > >> >>>>>
> > >> >>>>> ...
> > >> >>>>> Session session = connection.createSession(false,
> > >> >>>>> Session.AUTO_ACKNOWLEDGE);
> > >> >>>>> Queue queue = session.createQueue("$management");
> > >> >>>>> MessageProducer producer = session.createProducer(queue);
> > >> >>>>>
> > >> >>>>> Queue tempDest = session.createTemporaryQueue();
> > >> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDes
> > t);
> > >> >>>>> connection.start();
> > >> >>>>>
> > >> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
> > >> >>>>> objectMessage.setJMSReplyTo(tempDest);
> > >> >>>>> //fill the rest of the parameters ...
> > >> >>>>> producer.send(objectMessage);
> > >> >>>>> ObjectMessage replyMessage = (ObjectMessage)
> > >> >>>>> responseConsumer.receive(1000);
> > >> >>>>> ...
> > >> >>>>>
> > >> >>>>> I was getting an exception on the .receive() from the dispatch
> > router
> > >> >>>>> saying that the reply-to address is bad...
> > >> >>>>> Should i create the temporary queue and the consumer from a
> > different
> > >> >>>>> session then the producer?
> > >> >>>>>
> > >> >>>>> Best regards,
> > >> >>>>> Rabih
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
> > >> >>>>> robbie.gemmell@gmail.com>
> > >> >>>>> wrote:
> > >> >>>>>
> > >> >>>>> The session.createTemporaryQueue(); method is how JMS creates
> > >> >>>>>> temporary destinations for use in reply-to scenarios. The
> > dispatch
> > >> >>>>>> tools will be doing essentially the same thing under the covers
> > for
> > >> >>>>>> theirs.
> > >> >>>>>>
> > >> >>>>>> Both work by creating a 'dynamic' link attachment, with the
> > server
> > >> >>>>>> returning an address for the dynamic attach to the client. One
> > key
> > >> >>>>>> difference is with JMS you create the temporary destination (for
> > >> which
> > >> >>>>>> the client uses a dynamic sender link to create), then separately
> > >> >>>>>> create a receiver using it (and in turn the address associated
> > with
> > >> >>>>>> it), whereas non-JMS client/tools will typically just create a
> > >> single
> > >> >>>>>> dynamic receiver link and use its address for the reply-to.
> > >> >>>>>>
> > >> >>>>>> For proton-j, there aren't any examples for this, but you you
> > >> >>>>>> essentially would change the link opening to not specify an
> > address,
> > >> >>>>>> and instead set the source(for a receiver) or target (for a
> > sender)
> > >> to
> > >> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
> > >> remoteTarget
> > >> >>>>>> once the link had been reemotely attached, and get its
> > >> >>>>>> (server-generated) address, then use this as your reply-to.
> > >> >>>>>>
> > >> >>>>>> Robbie
> > >> >>>>>>
> > >> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
> > >> wrote:
> > >> >>>>>>
> > >> >>>>>>> Hello,
> > >> >>>>>>>
> > >> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like
> > you
> > >> >>>>>>> suggested, it worked.
> > >> >>>>>>> But I cheated a little to make it work because I did not find a
> > >> way in
> > >> >>>>>>>
> > >> >>>>>> JMS
> > >> >>>>>>
> > >> >>>>>>> to create a local queue. So I created a queue on the
> > qpid-dispatch
> > >> and
> > >> >>>>>>>
> > >> >>>>>> read
> > >> >>>>>>
> > >> >>>>>>> the result from it. You can check the attached code.
> > >> >>>>>>>
> > >> >>>>>>> Is there any way using qpid-jms to create a local queue on the
> > >> client
> > >> >>>>>>>
> > >> >>>>>> side
> > >> >>>>>>
> > >> >>>>>>> to serve as a reply to address?
> > >> >>>>>>>
> > >> >>>>>>> For the proton-j test, I have the same question as above. I saw
> > >> that
> > >> >>>>>>> it
> > >> >>>>>>>
> > >> >>>>>> can
> > >> >>>>>>
> > >> >>>>>>> be done with the C++ API. Are there any examples for proton-j or
> > >> >>>>>>>
> > >> >>>>>> something
> > >> >>>>>>
> > >> >>>>>>> that can help me?
> > >> >>>>>>>
> > >> >>>>>>> I saw may be in proton we don't need a local queue, may be we
> > can
> > >> get
> > >> >>>>>>> the
> > >> >>>>>>> address of the consumer directly and pass it in reply-to field.
> > Is
> > >> it
> > >> >>>>>>> correct?
> > >> >>>>>>>
> > >> >>>>>>> Thanks,
> > >> >>>>>>> Rabih
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
> > >> >>>>>>> rob.j.godfrey@gmail.com>
> > >> >>>>>>> wrote:
> > >> >>>>>>>
> > >> >>>>>>>>
> > >> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gmurthy@redhat.com
> > >
> > >> >>>>>>>> wrote:
> > >> >>>>>>>>
> > >> >>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>> ----- Original Message -----
> > >> >>>>>>>>>
> > >> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
> > >> >>>>>>>>>> To: users@qpid.apache.org
> > >> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
> > >> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid
> > >> Jms
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
> > >> wrote:
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you
> > >> told
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>> me
> > >> >>>>>>
> > >> >>>>>>> Robbie and it worked.
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>> But like the proton-j case, the connector is not being
> > >> created on
> > >> >>>>>>>>>>>> the
> > >> >>>>>>>>>>>> Qpid-dispatch side.
> > >> >>>>>>>>>>>> I attached the amqp communication into this mail.
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> The last frame in that file is incomplete (the previous
> > error
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>> regarding the
> > >> >>>>>>>>>
> > >> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
> > >> frame
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>> is
> > >> >>>>>>
> > >> >>>>>>> likely
> > >> >>>>>>>>>
> > >> >>>>>>>>>> the response which would indicate the success or otherwise of
> > >> the
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>> frame. Is
> > >> >>>>>>>>>
> > >> >>>>>>>>>> there anything logged by the router?
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
> > >> simpler
> > >> >>>>>>>>>>> for
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>> this
> > >> >>>>>>>>>
> > >> >>>>>>>>>> sort of thing in my view.
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more
> > helpful.
> > >> >>>>>>>>>> You
> > >> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
> > >> since
> > >> >>>>>>>>>> it
> > >> >>>>>>>>>> uses proton-j.
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> One key difference from the qdmanage case is you are not
> > >> setting a
> > >> >>>>>>>>>> reply-to value or correlation-id to use along with it. I
> > don't
> > >> know
> > >> >>>>>>>>>>
> > >> >>>>>>>>> if
> > >> >>>>>>
> > >> >>>>>>> the router cares about not being able to send a response or not
> > >> >>>>>>>>>> though, but it might.
> > >> >>>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>> You could add the following to your dispatch router conf file
> > >> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable
> > trace
> > >> >>>>>>>>>
> > >> >>>>>>>> logging)
> > >> >>>>>>
> > >> >>>>>>>
> > >> >>>>>>>>> log {
> > >> >>>>>>>>> module: DEFAULT
> > >> >>>>>>>>> enable: trace+
> > >> >>>>>>>>> output: /path/to/log/qdrouterd.log
> > >> >>>>>>>>> }
> > >> >>>>>>>>>
> > >> >>>>>>>>> When you run your management request, you will see proton
> > frame
> > >> >>>>>>>>> trace
> > >> >>>>>>>>> and
> > >> >>>>>>>>> you will see additional logging out of the dispatch Python
> > agent
> > >> -
> > >> >>>>>>>>> something like the following -
> > >> >>>>>>>>>
> > >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
> > >> >>>>>>>>> Message(address=None,
> > >> >>>>>>>>> properties={'operation': 'CREATE', 'type':
> > >> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
> > >> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
> > >> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
> > >> >>>>>>>>>
> > >> >>>>>>>> 'rabih.connector'},
> > >> >>>>>>
> > >> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
> > >> >>>>>>>>> correlation_id=1L)
> > >> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
> > >> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
> > >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
> > >> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True,
> > cost=1,
> > >> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
> > >> 5673:rabih.connector,
> > >> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
> > >> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
> > >> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.
> > connector,
> > >> >>>>>>>>> verifyHostName=True)
> > >> >>>>>>>>>
> > >> >>>>>>>>> The Python management agent will not process your request if
> > >> there
> > >> >>>>>>>>> is
> > >> >>>>>>>>>
> > >> >>>>>>>> no
> > >> >>>>>>
> > >> >>>>>>> reply_to as seen here -
> > >> >>>>>>>>>
> > >> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
> > >> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
> > >> because
> > >> >>>>>>>> there
> > >> >>>>>>>> is
> > >> >>>>>>>> a reply-to doesn't mean that the sender will be around to
> > actually
> > >> >>>>>>>> hear
> > >> >>>>>>>> the
> > >> >>>>>>>> reply, so it seems a bit arbitrary to say that because we
> > *know*
> > >> the
> > >> >>>>>>>> sender
> > >> >>>>>>>> won't learn of the outcome that we won't do anything... The
> > spec
> > >> >>>>>>>> draft
> > >> >>>>>>>> doesn't currently say anything about this (obviously it should
> > >> do),
> > >> >>>>>>>> but
> > >> >>>>>>>>
> > >> >>>>>>> my
> > >> >>>>>>
> > >> >>>>>>> expectation would certainly be that a request would be processed
> > >> even
> > >> >>>>>>>> if
> > >> >>>>>>>> the replyTo address was not present (or ended up not routing
> > >> >>>>>>>> anywhere).
> > >> >>>>>>>> This is also how the Qpid Broker for Java implements this case.
> > >> >>>>>>>>
> > >> >>>>>>>> -- Rob
> > >> >>>>>>>>
> > >> >>>>>>>>
> > >> >>>>>>>> Thanks.
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>>> Robbie
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> ------------------------------------------------------------
> > >> >>>>>>>>>>
> > >> >>>>>>>>> ---------
> > >> >>>>>>
> > >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>
> > >> >>>>>>>>> ------------------------------------------------------------
> > >> >>>>>>>>> ---------
> > >> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>> ------------------------------------------------------------
> > >> ---------
> > >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>>>>>>
> > >> >>>>>>
> > >> >>>>>> ------------------------------------------------------------
> > >> ---------
> > >> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>> ------------------------------------------------------------
> > ---------
> > >> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >>>> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>>>
> > >> >>>>
> > >> >>> ------------------------------------------------------------
> > ---------
> > >> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >>> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>>
> > >> >>>
> > >> >> ------------------------------------------------------------
> > ---------
> > >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>
> > >> >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> For additional commands, e-mail: users-help@qpid.apache.org
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Ganesh Murthy <gm...@redhat.com>.
----- Original Message -----
> From: "Adel Boutros" <Ad...@live.com>
> To: users@qpid.apache.org
> Sent: Wednesday, February 22, 2017 10:58:42 AM
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> Hello,
>
>
> One more issue: I am trying to replicate a "qdstat -a" to get the statistics
> of the addresses.
>
> It seems the 'name' and 'identity' fields returned are always prefixed by
> some weird combinations "L" or "M0" or "L$", etc. Is this expected?
>
The "L" or "M" etc are used by qdstat to display some additional information in its output.
If you look in the qdstat python program, you will see the following -
def _addr_class(self, addr):
if not addr:
return ""
if addr[0] == 'M' : return "mobile"
if addr[0] == 'R' : return "router"
if addr[0] == 'A' : return "area"
if addr[0] == 'L' : return "local"
if addr[0] == 'T' : return "topo"
if addr[0] == 'C' : return "link-in"
if addr[0] == 'D' : return "link-out"
return "unknown: %s" % addr[0]
But, I agree that the addresses themselves should not have these prefixes.
There is a JIRA for this already -
https://issues.apache.org/jira/browse/DISPATCH-450
I am not sure we can get to this before the 0.8 release but we will try.
In the meantime, you could use the same logic that qdstat uses.
Thanks.
>
> Output
>
> --------------
>
> attributeNames: [name, identity, type, key, distribution, inProcess,
> subscriberCount, remoteCount, containerCount, remoteHostRouters,
> deliveriesIngress, deliveriesEgress, deliveriesTransit,
> deliveriesToContainer, deliveriesFromContainer, transitOutstanding,
> trackedDeliveries]
>
> results: [[Lqdhello, Lqdhello, org.apache.qpid.dispatch.router.address,
> Lqdhello, flood, 1, 0, 0, 0, [], 0, 0, 0, 0, 1379, null, 0], [Lqdrouter,
> Lqdrouter, org.apache.qpid.dispatch.router.address, Lqdrouter, flood, 1, 0,
> 0, 0, [], 0, 0, 0, 0, 0, null, 0], [Lqdrouter.ma, Lqdrouter.ma,
> org.apache.qpid.dispatch.router.address, Lqdrouter.ma, multicast, 1, 0, 0,
> 0, [], 0, 0, 0, 0, 0, null, 0], [Tqdrouter, Tqdrouter,
> org.apache.qpid.dispatch.router.address, Tqdrouter, flood, 1, 0, 0, 0, [],
> 0, 0, 0, 0, 46, null, 0], [Tqdrouter.ma, Tqdrouter.ma,
> org.apache.qpid.dispatch.router.address, Tqdrouter.ma, multicast, 1, 0, 0,
> 0, [], 0, 0, 0, 0, 2, null, 0], [M0$management, M0$management,
> org.apache.qpid.dispatch.router.address, M0$management, closest, 1, 0, 0, 0,
> [], 7, 0, 0, 7, 0, null, 0], [L$management, L$management,
> org.apache.qpid.dispatch.router.address, L$management, closest, 1, 0, 0, 0,
> [], 0, 0, 0, 0, 0, null, 0], [L$_management_internal,
> L$_management_internal, org.apache.qpid.dispatch.router.address,
> L$_management_internal, closest, 1, 0, 0, 0, [], 0, 0, 0, 0, 0, null, 0],
> [L$displayname, L$displayname, org.apache.qpid.dispatch.router.address,
> L$displayname, closest, 1, 0, 0, 0, [], 0, 0, 0, 0, 0, null, 0],
> [M0$management_reply_queue, M0$management_reply_queue,
> org.apache.qpid.dispatch.router.address, M0$management_reply_queue,
> balanced, 0, 1, 0, 0, [], 0, 0, 0, 0, 0, null, 0]]
>
>
>
> Code
>
> ---------------
>
> ConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://green-lx-slave1:10501");
> Connection managementConnection = connectionFactory.createConnection();
> Session managementSession = managementConnection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> Queue managementQueue = managementSession.createQueue("$management");
> MessageProducer managementProducer =
> managementSession.createProducer(managementQueue);
> Queue replyToQueue =
> managementSession.createQueue("$management_reply_queue");
> MessageConsumer managementConsumer =
> managementSession.createConsumer(replyToQueue);
> managementConnection.start();
>
> // An object message should be used because the Map and List content must be
> encoded with AMQP encoding.
> ObjectMessage objectMessage = managementSession.createObjectMessage();
>
> // Setting management message header properties
> // JMS_AMQP_TYPED_ENCODING is a temporary solution that is used by qpid-jms
> to encode the message content with AMQP encoding before sending it.
> objectMessage.setBooleanProperty("JMS_AMQP_TYPED_ENCODING", true);
> objectMessage.setStringProperty("operation", "QUERY");
> objectMessage.setStringProperty("type",
> "org.apache.qpid.dispatch.router.address");
> objectMessage.setStringProperty("name", "self");
> objectMessage.setJMSReplyTo(replyToQueue);
>
> managementProducer.send(objectMessage);
>
> ObjectMessage replyMessage = (ObjectMessage) managementConsumer.receive();
>
> Map<String, Object> resultObject = (Map<String, Object>)
> replyMessage.getObject();
> for (Map.Entry<String, Object> entry : resultObject.entrySet()) {
> System.out.println(entry.getKey() + ": " + entry.getValue());
> }
>
> managementConnection.close();
>
> Regards,
>
> Adel
> ________________________________
> From: Adel Boutros <Ad...@live.com>
> Sent: Wednesday, February 22, 2017 12:33:32 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> Hello guys,
>
>
> My basic JMS API is almost ready. I will share it with you soon to have your
> feedback.
>
>
> However, I tried one last thing by getting a random queue name and using it
> as management reply queue to allow multiple configuration sessions
> simultaneously but it didn't work.
>
>
> //This doesn't work and crashes the dispatch router
>
> TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
> replyToQueue = managementSession.createQueue(temporaryQueue.getQueueName());
> managementConsumer = managementSession.createConsumer(replyToQueue);
>
> //This is the only thing working
> replyToQueue = managementSession.createQueue("HARD_CODED_REPLY_QUEUE");
> managementConsumer = managementSession.createConsumer(replyToQueue);
>
>
> Can I have your input on the above?
>
> Regards,
> Adel
>
>
> ________________________________
> From: Rob Godfrey <ro...@gmail.com>
> Sent: Wednesday, February 15, 2017 4:46:59 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> On 15 February 2017 at 16:07, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
> > On 15 February 2017 at 14:15, Adel Boutros <Ad...@live.com> wrote:
> > > Hello guys,
> > >
> > >
> > > Based on the discussion, we are currently writing a Java API based on
> > JMS to configure the dispatch router. I have so far managed to do the
> > following:
> > >
> > > * Create, Read, Delete addresses
> > >
> > > * Create, Read, Delete connectors
> > >
> > >
> > > Config:
> > >
> > > Dispatch Router 0.7.0
> > >
> > > JMS 0.11.1
> > >
> > >
> > > And I have noticed some problems and differences:
> > >
> > >
> > > 1) It seems some calls return ObjectMessage and some TextMessage (This
> > is on the side of the consumer in the replyTo)
> > >
> > > For example, creating twice the same queue will fail but the second call
> > will return a JmsTextMessage with an empty body and status code 400
> > >
> >
> > The client treats messages with an amqp-value sectioning containing
> > null/nothing as a TextMessage with null value if they arent annotated
> > to say otherwise, I'd guess thats where that comes from.
> >
> > >
> > > 2) Returned statusCode differs between Connector and Address
> > >
> > > Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
> > >
> > >
> > > * Connector operations return java.lang.Long
> > > * Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
> > >
> >
> > The router is presumably sending different values back for the
> > different operations here, a long and a uint. The router should
> > perhaps be consistent, and the client should perhaps not be returning
> > the uint object either way.
> >
> > The last draft of the management spec seems to say the status code
> > should be 'integer', im not clear if it means int (not uint)
> > specifically, or just any integral type value.
> >
> >
> The specification should definitely say which type should - so we'll fix
> that in the next draft. I'd suggest we should int (in AMQP terms) leading
> to a java.lang.Integer type in the property you see through Java.
>
> -- Rob
>
>
>
> > >
> > > 3) Create connector twice makes dispatch router crash. I don't have the
> > issue when creating addresses.
> > > On the second create call, JMS client receives a normal reply
> > containing a statusCode of an exception. After I close the connection to
> > the dispatch router via JMS (connection.close), I have the below crash
> > >
> > > (gdb) where
> > > #0 0x00007f27194448a5 in raise () from /lib64/libc.so.6
> > > #1 0x00007f2719446085 in abort () from /lib64/libc.so.6
> > > #2 0x00007f27194827b7 in __libc_message () from /lib64/libc.so.6
> > > #3 0x00007f27194880e6 in malloc_printerr () from /lib64/libc.so.6
> > > #4 0x00007f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf
> > expression opcode 0xf3
> > > ) at /qpid-dispatch-0.7.0/src/hash.c:320
> > > #5 0x00007f271a42247d in qdr_route_check_id_for_deletion_CT
> > (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
> > > ) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
> > > #6 0x00007f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30,
> > action=Unhandled dwarf expression opcode 0xf3
> > > ) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
> > > #7 0x00007f271a423f30 in router_core_thread (arg=0x13d2d30) at
> > /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
> > > #8 0x00007f2719f8c851 in start_thread () from /lib64/libpthread.so.0
> > > #9 0x00007f27194fa90d in clone () from /lib64/libc.so.6
> > >
> > >
> > > Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE:
> > org.apache.qpid.dispatch.connector: Duplicate value 'connector/
> > 127.0.0.1:5915:dispatch_management_connector_test' for unique attribute
> > 'identity'
> > > *** glibc detected *** /Dispatch/sbin/qdrouterd: double free or
> > corruption (fasttop): 0x00007f2708033f10 ***
> > > ======= Backtrace: =========
> > > /lib64/libc.so.6(+0x760e6)[0x7f27194880e6]
> > > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> > .so(qd_hash_remove_by_handle+0x29)[0x7f271a40f109]
> > > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> > .so(+0x3547d)[0x7f271a42247d]
> > > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> > .so(+0x318d3)[0x7f271a41e8d3]
> > > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> > .so(router_core_thread+0x230)[0x7f271a423f30]
> > > /lib64/libpthread.so.0(+0x7851)[0x7f2719f8c851]
> > > /lib64/libc.so.6(clone+0x6d)[0x7f27194fa90d]
> > > ======= Memory map: ========
> > > 00400000-00403000 r-xp 00000000 fd:01 7735642
> > /Dispatch/sbin/qdrouterd
> > > 00603000-00604000 rw-p 00003000 fd:01 7735642
> > /Dispatch/sbin/qdrouterd
> > > 01113000-01458000 rw-p 00000000 00:00 0
> > [heap]
> > > 7f26f8000000-7f26f805c000 rw-p 00000000 00:00 0
> > > 7f26f805c000-7f26fc000000 ---p 00000000 00:00 0
> > > 7f26fc000000-7f26fc043000 rw-p 00000000 00:00 0
> > > 7f26fc043000-7f2700000000 ---p 00000000 00:00 0
> > > 7f2700000000-7f2700085000 rw-p 00000000 00:00 0
> > > 7f2700085000-7f2704000000 ---p 00000000 00:00 0
> > > 7f27073e9000-7f27073ff000 r-xp 00000000 fd:00 524293
> > /lib64/libgcc_s-4.4.7-20120601.so.1
> > > 7f27073ff000-7f27075fe000 ---p 00016000 fd:00 524293
> > /lib64/libgcc_s-4.4.7-20120601.so.1
> > > 7f27075fe000-7f27075ff000 rw-p 00015000 fd:00 524293
> > /lib64/libgcc_s-4.4.7-20120601.so.1
> > > 7f27075ff000-7f2707600000 ---p 00000000 00:00 0
> > > 7f2707600000-7f2708000000 rw-p 00000000 00:00 0
> > > 7f2708000000-7f270805a000 rw-p 00000000 00:00 0
> > > 7f270805a000-7f270c000000 ---p 00000000 00:00 0
> > > 7f270c04a000-7f270c04f000 r-xp 00000000 fd:00 524322
> > /lib64/libnss_dns-2.12.so
> > > 7f270c04f000-7f270c24e000 ---p 00005000 fd:00 524322
> > /lib64/libnss_dns-2.12.so
> > > 7f270c24e000-7f270c24f000 r--p 00004000 fd:00 524322
> > /lib64/libnss_dns-2.12.so
> > > 7f270c24f000-7f270c250000 rw-p 00005000 fd:00 524322
> > /lib64/libnss_dns-2.12.so
> > > 7f270c250000-7f270c251000 ---p 00000000 00:00 0
> > > 7f270c251000-7f270cc51000 rw-p 00000000 00:00 0
> > > 7f270cc51000-7f270cc52000 ---p 00000000 00:00 0
> > > 7f270cc52000-7f270d652000 rw-p 00000000 00:00 0
> > > 7f270d652000-7f270d65e000 r-xp 00000000 fd:00 524324
> > /lib64/libnss_files-2.12.so
> > > 7f270d65e000-7f270d85e000 ---p 0000c000 fd:00 524324
> > /lib64/libnss_files-2.12.so
> > > 7f270d85e000-7f270d85f000 r--p 0000c000 fd:00 524324
> > /lib64/libnss_files-2.12.so
> > > 7f270d85f000-7f270d860000 rw-p 0000d000 fd:00 524324
> > /lib64/libnss_files-2.12.so
> > > 7f270d86a000-7f270d86b000 ---p 00000000 00:00 0
> > > 7f270d86b000-7f270e3ac000 rw-p 00000000 00:00 0
> > > 7f270e3ac000-7f270e3b1000 r-xp 00000000 00:16 4090944
> > /python278/lib/python2.7/lib-dynload/select.so
> > > 7f270e3b1000-7f270e5b0000 ---p 00005000 00:16 4090944
> > /python278/lib/python2.7/lib-dynload/select.so
> > > 7f270e5b0000-7f270e5b2000 rw-p 00004000 00:16 4090944
> > /python278/lib/python2.7/lib-dynload/select.so
> > > 7f270e5b2000-7f270e5b6000 r-xp 00000000 00:16 5568743
> > /python278/lib/python2.7/lib-dynload/_lsprof.so
> > > 7f270e5b6000-7f270e7b5000 ---p 00004000 00:16 5568743
> > /python278/lib/python2.7/lib-dynload/_lsprof.so
> > > 7f270e7b5000-7f270e7b6000 rw-p 00003000 00:16 5568743
> > /python278/lib/python2.7/lib-dynload/_lsprof.so
> > > 7f270e7b6000-7f270e8b7000 rw-p 00000000 00:00 0
> > > 7f270e8b7000-7f270e8bc000 r-xp 00000000 00:16 6394000
> > /python278/lib/python2.7/lib-dynload/strop.so
> > > 7f270e8bc000-7f270eabb000 ---p 00005000 00:16 6394000
> > /python278/lib/python2.7/lib-dynload/strop.so
> > > 7f270eabb000-7f270eabd000 rw-p 00004000 00:16 6394000
> > /python278/lib/python2.7/lib-dynload/strop.so
> > > 7f270eabd000-7f270eafd000 rw-p 00000000 00:00 0
> > > 7f270eafd000-7f270eb00000 r-xp 00000000 00:16 5568749
> > /python278/lib/python2.7/lib-dynload/fcntl.so
> > > 7f270eb00000-7f270ecff000 ---p 00003000 00:16 5568749
> > /python278/lib/python2.7/lib-dynload/fcntl.so
> > > 7f270ecff000-7f270ed01000 rw-p 00002000 00:16 5568749
> > /python278/lib/python2.7/lib-dynload/fcntl.so
> > > 7f270ed01000-7f270ed04000 r-xp 00000000 00:16 5568739
> > /python278/lib/python2.7/lib-dynload/_random.so
> > > 7f270ed04000-7f270ef03000 ---p 00003000 00:16 5568739
> > /python278/lib/python2.7/lib-dynload/_random.so
> > > 7f270ef03000-7f270ef04000 rw-p 00002000 00:16 5568739
> > /python278/lib/python2.7/lib-dynload/_random.so
> > > 4272 Aborted (core dumped)
> > >
> > >
> > > Regards,
> > > Adel
> > >
> > >
> > > ________________________________
> > > From: Rob Godfrey <ro...@gmail.com>
> > > Sent: Monday, February 6, 2017 7:09 PM
> > > To: users@qpid.apache.org
> > > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> > >
> > > On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
> > > wrote:
> > >
> > >> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com>
> > wrote:
> > >> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
> > >> >
> > >> >> It seems odd that the client creates a _sender_ to the temporary
> > queue
> > >> >> that it will never send messages _to_ but will receive messages
> > _from_.
> > >> >>
> > >> >>
> > >> > This is because JMS semantics require the temporary node to have a
> > >> lifetime
> > >> > scoped to the session (not a link), so the JMS client has to create a
> > >> > synthetic link which it uses simply to manage the lifetime of the
> > dynamic
> > >> > node. In order to not cause unintentional assigning of messages to a
> > >> link
> > >> > that will never actually be used for consumption, a sending link is
> > used.
> > >> > Note that in general JMS would expect that you should be able to send
> > to
> > >> a
> > >> > temporary queue created in this way (since the point of temporary
> > queues
> > >> is
> > >> > to use as a reply to)
> > >> >
> > >>
> > >> Not really important here, but the lifetime is scoped to the
> > >> Connection, not Session (agghhh JMS... :P)
> > >>
> > >
> > > That's what I thought I was typing... obviously my fingers were not
> > > cooperating with my brain at that point :-)
> > >
> > > -- Rob
> > >
> > >
> > >>
> > >> >
> > >> >> Anyway, when the client creates a receiver with a dynamic source
> > (and no
> > >> >> dynamic-node-properties), the router will accept the link and assign
> > a
> > >> >> temporary address as the source. This is only useful in this use
> > case
> > >> if
> > >> >> the broker has a way of knowing that the temporary address is
> > reachable
> > >> via
> > >> >> the router network.
> > >> >>
> > >> >> There is a way to route dynamic termini to a broker. If an
> > >> >> x-opt-qd.address property is included in the dynamic-node-properties,
> > >> this
> > >> >> address will be used to route the attach to the broker. I've never
> > >> tested
> > >> >> this with a dynamic target in a sender. It might not work.
> > >> >
> > >> >
> > >> > And this really isn't something you'd be expecting a generic client
> > (like
> > >> > the JMS client) to know :-)
> > >> >
> > >> > -- Rob
> > >> >
> > >> >
> > >> >>
> > >> >>
> > >> >> -Ted
> > >> >>
> > >> >>
> > >> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
> > >> >>
> > >> >>> I've had a look at this. It would seem that Dispatch doesn't like
> > what
> > >> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
> > >> >>> very nice way, and the client then doesnt notice that things have
> > gone
> > >> >>> south in a somewhat unexpected way.
> > >> >>>
> > >> >>> The client opens a sending link with 'dynamic' target in order to
> > >> >>> create a dynamic node for use as a TemporaryQueue
> > address/destination
> > >> >>> object, which specific consumers/producers are then created against
> > by
> > >> >>> the application. Dispatch doesn't seem to like that but erroneously
> > >> >>> attaches the link 'successfully', though doesnt set a target address
> > >> >>> as is expected. The client then doesnt notice this happened (its
> > >> >>> checking for the link being refused, which it wasn't), allowing the
> > >> >>> application to proceed as far as creating consumers/procuers using
> > the
> > >> >>> TemporaryQueue object, with creation of the e.g Consumer then
> > failing
> > >> >>> since the attach doesnt contain the needed information and leads to
> > >> >>> Dispatch detaching it with the error (though it again doesnt
> > actually
> > >> >>> indicate its refusing the link during the attach response, as it
> > >> >>> probably should have in this case).
> > >> >>>
> > >> >>> Making the client detect the current failure and having it throw an
> > >> >>> aexception from createTemporaryQueue is simple enough.
> > >> >>>
> > >> >>> Hacking the client to use a dynamic recieving link instead, an
> > address
> > >> >>> was returned by Dispatch in the attach response as expected,
> > however a
> > >> >>> consumer on the resulting TemporaryQueue object using this address
> > >> >>> still didnt get the message I sent to the same place. If I also gave
> > >> >>> some credit on the link backing the TemporaryQeueue object itself
> > then
> > >> >>> that link gets sent the message by Dispatch, though this of no use
> > for
> > >> >>> the JMS client.
> > >> >>>
> > >> >>> Needs some more investigation, and I'll need to discuss with some
> > >> >>> folks more familiar with Dispatch.
> > >> >>>
> > >> >>> Robbie
> > >> >>>
> > >> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
> > >> wrote:
> > >> >>>
> > >> >>>> Hello Robbie,
> > >> >>>>
> > >> >>>>
> > >> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the
> > reply
> > >> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS
> > Client.
> > >> >>>>
> > >> >>>>
> > >> >>>> PS: As Rabih stated before, we are using the same connection and
> > same
> > >> >>>> session to create the JMSProducer for the request and the
> > >> JMSConsumer for
> > >> >>>> the reply.
> > >> >>>>
> > >> >>>>
> > >> >>>> Exception
> > >> >>>> -------------------
> > >> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed
> > due
> > >> to
> > >> >>>> an unrecoverable error.
> > >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
> > >> >>>> eConsumer.java:330)
> > >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
> > >> >>>> sumer.java:196)
> > >> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
> > >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> > >> >>>> ssorImpl.java:62)
> > >> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> > >> >>>> thodAccessorImpl.java:43)
> > >> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
> > >> >>>> at com.intellij.rt.execution.application.AppMain.main(
> > >> AppMain.java:147)
> > >> >>>> Caused by: javax.jms.JMSException: No route to the destination node
> > >> >>>> [condition = qd:no-route-to-dest]
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> > >> >>>> tion(AmqpSupport.java:150)
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> > >> >>>> tion(AmqpSupport.java:105)
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
> > >> >>>> elyClosed(AmqpAbstractResource.java:147)
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
> > >> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
> > >> >>>> s(AmqpProvider.java:795)
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
> > >> >>>> mqpProvider.java:90)
> > >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
> > >> >>>> ovider.java:699)
> > >> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
> > >> >>>> Executors.java:511)
> > >> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> > >> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> > >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> > >> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
> > >> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> > >> >>>> Executor.java:1142)
> > >> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> > >> >>>> lExecutor.java:617)
> > >> >>>> at java.lang.Thread.run(Thread.java:745)
> > >> >>>>
> > >> >>>>
> > >> >>>> -------------------
> > >> >>>> Dispatch Router (PN_TRACE_FRM=1)
> > >> >>>> -------------------
> > >> >>>>
> > >> >>>> [832220]: <- SASL
> > >> >>>> [832220]: -> SASL
> > >> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
> > >> >>>> MBOL[:ANONYMOUS]]
> > >> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
> > >> >>>> initial-response=b"", hostname="host-name"]
> > >> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
> > >> >>>> [832220]: <- AMQP
> > >> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
> > >> a334-44c3-954a-2dd910161411:1",
> > >> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
> > >> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
> > >> >>>> L[:"sole-connection-for-container"],
> > properties={:product="QpidJMS",
> > >> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
> > >> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
> > >> >>>> [832220]: -> AMQP
> > >> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
> > >> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> > >> >>>> offered-capabilities=:"ANONYMOUS-RELAY",
> > properties={:product="qpid-
> > >> dispatch-router",
> > >> >>>> :version="0.7.0"}]
> > >> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> > >> >>>> outgoing-window=2147483647, handle-max=65535]
> > >> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
> > >> >>>> incoming-window=61, outgoing-window=2147483647]
> > >> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> > >> >>>> outgoing-window=2147483647, handle-max=65535]
> > >> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
> > >> >>>> incoming-window=61, outgoing-window=2147483647]
> > >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
> > >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> > >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
> > source=@source(40)
> > >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
> > durable=0,
> > >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> > >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list",
> > :"amqp:rejected:list"]],
> > >> >>>> target=@target(41) [address="$management", durable=0,
> > >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> > >> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
> > >> >>>> initial-delivery-count=0]
> > >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
> > >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> > >> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> > >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
> > durable=0,
> > >> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:acc
> > epted:list",
> > >> >>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
> > >> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
> > >> queue]],
> > >> >>>> initial-delivery-count=0, max-message-size=0]
> > >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> > >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> > >> delivery-count=0,
> > >> >>>> link-credit=250, drain=false]
> > >> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
> > >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> > >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
> > source=@source(40)
> > >> [],
> > >> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
> > >> timeout=0,
> > >> >>>> dynamic=true, dynamic-node-properties={:"lif
> > >> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
> > >> temporary-queue"]],
> > >> >>>> incomplete-unsettled=false, initial-delivery-count=0]
> > >> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
> > >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> > >> role=true,
> > >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> > [durable=0,
> > >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> > >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
> > >> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43)
> > []},
> > >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
> > >> initial-delivery-count=0,
> > >> >>>> max-message-size=0]
> > >> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> > >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> > >> delivery-count=0,
> > >> >>>> link-credit=250, drain=false]
> > >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
> > >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
> > role=true,
> > >> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> > [durable=0,
> > >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> > >> >>>> default-outcome=@modified(39) [delivery-failed=true],
> > >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> > >> >>>> :"amqp:released:list", :"amqp:modified:list"],
> > >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41)
> > []]
> > >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
> > >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
> > role=false,
> > >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> > [durable=0,
> > >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> > timeout=0,
> > >> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
> > >> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
> > >> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
> > >> >>>> destination node"]]
> > >> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
> > >> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
> > >> delivery-tag=b"0",
> > >> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
> > >> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
> > >> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
> > >> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
> > >> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
> > >> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
> > >> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
> > >> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
> > >> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
> > >> >>>> x04addr\xa1\x0dbrokerMachine"
> > >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
> > >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> > >> delivery-count=1,
> > >> >>>> link-credit=250, drain=false]
> > >> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
> > >> >>>> settled=true, state=@accepted(36) []]
> > >> >>>> [832220]:0 <- @close(24) []
> > >> >>>> [832220]: <- EOS
> > >> >>>> [832220]:0 -> @close(24) []
> > >> >>>> [832220]: -> EOS
> > >> >>>> Closed x.x.x.x:8961
> > >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> > >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> > >> >>>>
> > >> >>>> ------------------
> > >> >>>> JMS Client (PN_TRACE_FRM=1)
> > >> >>>> ------------------
> > >> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
> > >> 4a22-9b22-69d27a017a83:1',
> > >> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
> > >> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
> > >> connection-for-container],
> > >> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM:
> > 1.8.0_111,
> > >> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
> > >> >>>> [1244186219:0] <- Open{ containerId='router.10200',
> > hostname='null',
> > >> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
> > >> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
> > >> ANONYMOUS-RELAY],
> > >> >>>> desiredCapabilities=null, properties={product=qpid-dispa
> > tch-router,
> > >> >>>> version=0.7.0}}
> > >> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> > >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> > >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
> > >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
> > >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
> > >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
> > handle=0,
> > >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> > >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> > >> 3293ffc57168:1:1:1',
> > >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> > >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> > >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> > >> amqp:rejected:list],
> > >> >>>> capabilities=null}, target=Target{address='$management',
> > >> durable=NONE,
> > >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> > >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> > >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> > >> maxMessageSize=null,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
> > >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
> > handle=0,
> > >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> > >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> > >> 3293ffc57168:1:1:1',
> > >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> > >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> > >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> > >> amqp:rejected:list],
> > >> >>>> capabilities=null}, target=Target{address='$management',
> > >> durable=NONE,
> > >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> > >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> > >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> > maxMessageSize=0,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
> > >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> > >> deliveryCount=0,
> > >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> > >> properties=null}
> > >> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
> > >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> > >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> > >> >>>> source=Source{address='null', durable=NONE,
> > expiryPolicy=SESSION_END,
> > >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> > >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> > >> outcomes=null,
> > >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> > >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> > >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> > >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> > >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> > >> maxMessageSize=null,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
> > >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> > >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> > >> >>>> source=Source{address='null', durable=NONE,
> > expiryPolicy=SESSION_END,
> > >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> > >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> > >> outcomes=null,
> > >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> > >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> > >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> > >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> > >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> > maxMessageSize=0,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
> > >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> > >> deliveryCount=0,
> > >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> > >> properties=null}
> > >> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
> > >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> > >> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> > >> >>>> source=Source{address='null', durable=NONE,
> > expiryPolicy=LINK_DETACH,
> > >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> > >> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
> > >> deliveryFailed=true,
> > >> >>>> undeliverableHere=null, messageAnnotations=null},
> > >> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list,
> > amqp:released:list,
> > >> >>>> amqp:modified:list], capabilities=[temporary-queue]},
> > >> >>>> target=Target{address='null', durable=NONE,
> > expiryPolicy=SESSION_END,
> > >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> > >> capabilities=null},
> > >> >>>> unsettled=null, incompleteUnsettled=false,
> > initialDeliveryCount=null,
> > >> >>>> maxMessageSize=null, offeredCapabilities=null,
> > >> desiredCapabilities=null,
> > >> >>>> properties=null}
> > >> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
> > >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> > >> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> > >> >>>> source=Source{address='null', durable=NONE,
> > expiryPolicy=SESSION_END,
> > >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> > >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> > >> outcomes=null,
> > >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> > >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> > >> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> > >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> > maxMessageSize=0,
> > >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> > properties=null}
> > >> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
> > >> >>>> error=Error{condition=qd:no-route-to-dest, description='No route
> > to
> > >> the
> > >> >>>> destination node', info=null}}
> > >> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
> > >> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
> > >> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
> > >> state=null,
> > >> >>>> resume=false, aborted=false, batchable=false} (312)
> > >> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
> > >> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
> > >> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$man
> > agement@
> > >> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
> > >> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
> > >> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
> > >> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
> > >> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
> > >> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
> > >> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
> > >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> > >> deliveryCount=1,
> > >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> > >> properties=null}
> > >> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
> > >> >>>> settled=true, state=Accepted{}, batchable=false}
> > >> >>>> [1244186219:0] -> Close{error=null}
> > >> >>>> [1244186219:0] <- Close{error=null}
> > >> >>>>
> > >> >>>> Regards,
> > >> >>>>
> > >> >>>> Adel
> > >> >>>>
> > >> >>>> ________________________________
> > >> >>>> From: Robbie Gemmell <ro...@gmail.com>
> > >> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
> > >> >>>> To: users@qpid.apache.org
> > >> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> > >> >>>>
> > >> >>>> That looks fine at first glance. Its possible there is an issue in
> > >> >>>> there needing looked it. I am travelling this week so may not get
> > to
> > >> >>>> look until afterwards, but will try to give things a look at. If
> > you
> > >> >>>> could give more detail on the exception and maybe a protocol trace
> > >> >>>> that might be useful.
> > >> >>>>
> > >> >>>> Robbie
> > >> >>>>
> > >> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com>
> > wrote:
> > >> >>>>
> > >> >>>>> Hello Robbie,
> > >> >>>>>
> > >> >>>>> Thanks for you for your answer.
> > >> >>>>> I will try the solutions you proposed.
> > >> >>>>>
> > >> >>>>> I need just need one clarification. Concerning the Jms, I already
> > >> tried
> > >> >>>>> to
> > >> >>>>> use a temporary queue but it didn't work. May be i am using it
> > wrong.
> > >> >>>>> Here
> > >> >>>>> is what i did:
> > >> >>>>>
> > >> >>>>> ...
> > >> >>>>> Session session = connection.createSession(false,
> > >> >>>>> Session.AUTO_ACKNOWLEDGE);
> > >> >>>>> Queue queue = session.createQueue("$management");
> > >> >>>>> MessageProducer producer = session.createProducer(queue);
> > >> >>>>>
> > >> >>>>> Queue tempDest = session.createTemporaryQueue();
> > >> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDes
> > t);
> > >> >>>>> connection.start();
> > >> >>>>>
> > >> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
> > >> >>>>> objectMessage.setJMSReplyTo(tempDest);
> > >> >>>>> //fill the rest of the parameters ...
> > >> >>>>> producer.send(objectMessage);
> > >> >>>>> ObjectMessage replyMessage = (ObjectMessage)
> > >> >>>>> responseConsumer.receive(1000);
> > >> >>>>> ...
> > >> >>>>>
> > >> >>>>> I was getting an exception on the .receive() from the dispatch
> > router
> > >> >>>>> saying that the reply-to address is bad...
> > >> >>>>> Should i create the temporary queue and the consumer from a
> > different
> > >> >>>>> session then the producer?
> > >> >>>>>
> > >> >>>>> Best regards,
> > >> >>>>> Rabih
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
> > >> >>>>> robbie.gemmell@gmail.com>
> > >> >>>>> wrote:
> > >> >>>>>
> > >> >>>>> The session.createTemporaryQueue(); method is how JMS creates
> > >> >>>>>> temporary destinations for use in reply-to scenarios. The
> > dispatch
> > >> >>>>>> tools will be doing essentially the same thing under the covers
> > for
> > >> >>>>>> theirs.
> > >> >>>>>>
> > >> >>>>>> Both work by creating a 'dynamic' link attachment, with the
> > server
> > >> >>>>>> returning an address for the dynamic attach to the client. One
> > key
> > >> >>>>>> difference is with JMS you create the temporary destination (for
> > >> which
> > >> >>>>>> the client uses a dynamic sender link to create), then separately
> > >> >>>>>> create a receiver using it (and in turn the address associated
> > with
> > >> >>>>>> it), whereas non-JMS client/tools will typically just create a
> > >> single
> > >> >>>>>> dynamic receiver link and use its address for the reply-to.
> > >> >>>>>>
> > >> >>>>>> For proton-j, there aren't any examples for this, but you you
> > >> >>>>>> essentially would change the link opening to not specify an
> > address,
> > >> >>>>>> and instead set the source(for a receiver) or target (for a
> > sender)
> > >> to
> > >> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
> > >> remoteTarget
> > >> >>>>>> once the link had been reemotely attached, and get its
> > >> >>>>>> (server-generated) address, then use this as your reply-to.
> > >> >>>>>>
> > >> >>>>>> Robbie
> > >> >>>>>>
> > >> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
> > >> wrote:
> > >> >>>>>>
> > >> >>>>>>> Hello,
> > >> >>>>>>>
> > >> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like
> > you
> > >> >>>>>>> suggested, it worked.
> > >> >>>>>>> But I cheated a little to make it work because I did not find a
> > >> way in
> > >> >>>>>>>
> > >> >>>>>> JMS
> > >> >>>>>>
> > >> >>>>>>> to create a local queue. So I created a queue on the
> > qpid-dispatch
> > >> and
> > >> >>>>>>>
> > >> >>>>>> read
> > >> >>>>>>
> > >> >>>>>>> the result from it. You can check the attached code.
> > >> >>>>>>>
> > >> >>>>>>> Is there any way using qpid-jms to create a local queue on the
> > >> client
> > >> >>>>>>>
> > >> >>>>>> side
> > >> >>>>>>
> > >> >>>>>>> to serve as a reply to address?
> > >> >>>>>>>
> > >> >>>>>>> For the proton-j test, I have the same question as above. I saw
> > >> that
> > >> >>>>>>> it
> > >> >>>>>>>
> > >> >>>>>> can
> > >> >>>>>>
> > >> >>>>>>> be done with the C++ API. Are there any examples for proton-j or
> > >> >>>>>>>
> > >> >>>>>> something
> > >> >>>>>>
> > >> >>>>>>> that can help me?
> > >> >>>>>>>
> > >> >>>>>>> I saw may be in proton we don't need a local queue, may be we
> > can
> > >> get
> > >> >>>>>>> the
> > >> >>>>>>> address of the consumer directly and pass it in reply-to field.
> > Is
> > >> it
> > >> >>>>>>> correct?
> > >> >>>>>>>
> > >> >>>>>>> Thanks,
> > >> >>>>>>> Rabih
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
> > >> >>>>>>> rob.j.godfrey@gmail.com>
> > >> >>>>>>> wrote:
> > >> >>>>>>>
> > >> >>>>>>>>
> > >> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gmurthy@redhat.com
> > >
> > >> >>>>>>>> wrote:
> > >> >>>>>>>>
> > >> >>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>> ----- Original Message -----
> > >> >>>>>>>>>
> > >> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
> > >> >>>>>>>>>> To: users@qpid.apache.org
> > >> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
> > >> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid
> > >> Jms
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
> > >> wrote:
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you
> > >> told
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>> me
> > >> >>>>>>
> > >> >>>>>>> Robbie and it worked.
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>> But like the proton-j case, the connector is not being
> > >> created on
> > >> >>>>>>>>>>>> the
> > >> >>>>>>>>>>>> Qpid-dispatch side.
> > >> >>>>>>>>>>>> I attached the amqp communication into this mail.
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> The last frame in that file is incomplete (the previous
> > error
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>> regarding the
> > >> >>>>>>>>>
> > >> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
> > >> frame
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>> is
> > >> >>>>>>
> > >> >>>>>>> likely
> > >> >>>>>>>>>
> > >> >>>>>>>>>> the response which would indicate the success or otherwise of
> > >> the
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>> frame. Is
> > >> >>>>>>>>>
> > >> >>>>>>>>>> there anything logged by the router?
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
> > >> simpler
> > >> >>>>>>>>>>> for
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>> this
> > >> >>>>>>>>>
> > >> >>>>>>>>>> sort of thing in my view.
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more
> > helpful.
> > >> >>>>>>>>>> You
> > >> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
> > >> since
> > >> >>>>>>>>>> it
> > >> >>>>>>>>>> uses proton-j.
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> One key difference from the qdmanage case is you are not
> > >> setting a
> > >> >>>>>>>>>> reply-to value or correlation-id to use along with it. I
> > don't
> > >> know
> > >> >>>>>>>>>>
> > >> >>>>>>>>> if
> > >> >>>>>>
> > >> >>>>>>> the router cares about not being able to send a response or not
> > >> >>>>>>>>>> though, but it might.
> > >> >>>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>> You could add the following to your dispatch router conf file
> > >> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable
> > trace
> > >> >>>>>>>>>
> > >> >>>>>>>> logging)
> > >> >>>>>>
> > >> >>>>>>>
> > >> >>>>>>>>> log {
> > >> >>>>>>>>> module: DEFAULT
> > >> >>>>>>>>> enable: trace+
> > >> >>>>>>>>> output: /path/to/log/qdrouterd.log
> > >> >>>>>>>>> }
> > >> >>>>>>>>>
> > >> >>>>>>>>> When you run your management request, you will see proton
> > frame
> > >> >>>>>>>>> trace
> > >> >>>>>>>>> and
> > >> >>>>>>>>> you will see additional logging out of the dispatch Python
> > agent
> > >> -
> > >> >>>>>>>>> something like the following -
> > >> >>>>>>>>>
> > >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
> > >> >>>>>>>>> Message(address=None,
> > >> >>>>>>>>> properties={'operation': 'CREATE', 'type':
> > >> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
> > >> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
> > >> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
> > >> >>>>>>>>>
> > >> >>>>>>>> 'rabih.connector'},
> > >> >>>>>>
> > >> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
> > >> >>>>>>>>> correlation_id=1L)
> > >> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
> > >> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
> > >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
> > >> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True,
> > cost=1,
> > >> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
> > >> 5673:rabih.connector,
> > >> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
> > >> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
> > >> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.
> > connector,
> > >> >>>>>>>>> verifyHostName=True)
> > >> >>>>>>>>>
> > >> >>>>>>>>> The Python management agent will not process your request if
> > >> there
> > >> >>>>>>>>> is
> > >> >>>>>>>>>
> > >> >>>>>>>> no
> > >> >>>>>>
> > >> >>>>>>> reply_to as seen here -
> > >> >>>>>>>>>
> > >> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
> > >> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
> > >> because
> > >> >>>>>>>> there
> > >> >>>>>>>> is
> > >> >>>>>>>> a reply-to doesn't mean that the sender will be around to
> > actually
> > >> >>>>>>>> hear
> > >> >>>>>>>> the
> > >> >>>>>>>> reply, so it seems a bit arbitrary to say that because we
> > *know*
> > >> the
> > >> >>>>>>>> sender
> > >> >>>>>>>> won't learn of the outcome that we won't do anything... The
> > spec
> > >> >>>>>>>> draft
> > >> >>>>>>>> doesn't currently say anything about this (obviously it should
> > >> do),
> > >> >>>>>>>> but
> > >> >>>>>>>>
> > >> >>>>>>> my
> > >> >>>>>>
> > >> >>>>>>> expectation would certainly be that a request would be processed
> > >> even
> > >> >>>>>>>> if
> > >> >>>>>>>> the replyTo address was not present (or ended up not routing
> > >> >>>>>>>> anywhere).
> > >> >>>>>>>> This is also how the Qpid Broker for Java implements this case.
> > >> >>>>>>>>
> > >> >>>>>>>> -- Rob
> > >> >>>>>>>>
> > >> >>>>>>>>
> > >> >>>>>>>> Thanks.
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>>> Robbie
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> ------------------------------------------------------------
> > >> >>>>>>>>>>
> > >> >>>>>>>>> ---------
> > >> >>>>>>
> > >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>
> > >> >>>>>>>>> ------------------------------------------------------------
> > >> >>>>>>>>> ---------
> > >> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>> ------------------------------------------------------------
> > >> ---------
> > >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>>>>>>
> > >> >>>>>>
> > >> >>>>>> ------------------------------------------------------------
> > >> ---------
> > >> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>> ------------------------------------------------------------
> > ---------
> > >> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >>>> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>>>
> > >> >>>>
> > >> >>> ------------------------------------------------------------
> > ---------
> > >> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >>> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>>
> > >> >>>
> > >> >> ------------------------------------------------------------
> > ---------
> > >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>
> > >> >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> For additional commands, e-mail: users-help@qpid.apache.org
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Robbie Gemmell <ro...@gmail.com>.
Great, thanks Ganesh.
Robbie
On 27 February 2017 at 22:19, Ganesh Murthy <gm...@redhat.com> wrote:
> Hi Robbie,
>
> ----- Original Message -----
>> From: "Robbie Gemmell" <ro...@gmail.com>
>> To: users@qpid.apache.org
>> Sent: Friday, February 24, 2017 11:43:05 AM
>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>
>> I tried this (modified to use a temporary queue) and also modified the
>> Qpid JMS HelloWorld example to use a temporary queue, and ran both
>> against the router successfully multiple times, using the jms client
>> from master, dispatch from master, and proton from master.
>>
>> The only odd thing was that Dispatch printed out two copies of notices
>> about the connection closing without the links being explicitly
>> detached, which is what the examples do and not something I would
>> consider unusual. I wouldnt really expect to see these notices, but if
>> so then only one copy.
>>
>> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
>> 'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
>> due to parent connection end
>> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
>> 'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
>> due to parent connection end
>> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
>> 'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
>> due to parent connection end
>> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
>> 'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
>> due to parent connection end
>> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
>> 'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
>> due to parent connection end
>> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
>> 'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
>> due to parent connection end
>>
>
> These log messages should not appear in the case of running the Qpid JMS Hello World examples. These are supposed to appear only
> when a socket close is received. I have entered a JIRA for this -
> https://issues.apache.org/jira/browse/DISPATCH-643
>
> I have fixed this issue on master branch.
>
> Thanks much.
>
>> As an aside, the typical TemporaryQueue usage would be just to use the
>> destination object directly, i.e the below, not ask its name and
>> create another destination with that name. I tried both ways just to
>> check it wasnt related though and they both worked the same.
>> TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
>> managementConsumer = managementSession.createConsumer(temporaryQueue);
>>
>>
>> On 22 February 2017 at 11:33, Adel Boutros <Ad...@live.com> wrote:
>> > Hello guys,
>> >
>> >
>> > My basic JMS API is almost ready. I will share it with you soon to have
>> > your feedback.
>> >
>> >
>> > However, I tried one last thing by getting a random queue name and using it
>> > as management reply queue to allow multiple configuration sessions
>> > simultaneously but it didn't work.
>> >
>> >
>> > //This doesn't work and crashes the dispatch router
>> >
>> > TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
>> > replyToQueue =
>> > managementSession.createQueue(temporaryQueue.getQueueName());
>> > managementConsumer = managementSession.createConsumer(replyToQueue);
>> >
>> > //This is the only thing working
>> > replyToQueue = managementSession.createQueue("HARD_CODED_REPLY_QUEUE");
>> > managementConsumer = managementSession.createConsumer(replyToQueue);
>> >
>> >
>> > Can I have your input on the above?
>> >
>> > Regards,
>> > Adel
>> >
>> >
>> > ________________________________
>> > From: Rob Godfrey <ro...@gmail.com>
>> > Sent: Wednesday, February 15, 2017 4:46:59 PM
>> > To: users@qpid.apache.org
>> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>> >
>> > On 15 February 2017 at 16:07, Robbie Gemmell <ro...@gmail.com>
>> > wrote:
>> >
>> >> On 15 February 2017 at 14:15, Adel Boutros <Ad...@live.com> wrote:
>> >> > Hello guys,
>> >> >
>> >> >
>> >> > Based on the discussion, we are currently writing a Java API based on
>> >> JMS to configure the dispatch router. I have so far managed to do the
>> >> following:
>> >> >
>> >> > * Create, Read, Delete addresses
>> >> >
>> >> > * Create, Read, Delete connectors
>> >> >
>> >> >
>> >> > Config:
>> >> >
>> >> > Dispatch Router 0.7.0
>> >> >
>> >> > JMS 0.11.1
>> >> >
>> >> >
>> >> > And I have noticed some problems and differences:
>> >> >
>> >> >
>> >> > 1) It seems some calls return ObjectMessage and some TextMessage (This
>> >> is on the side of the consumer in the replyTo)
>> >> >
>> >> > For example, creating twice the same queue will fail but the second call
>> >> will return a JmsTextMessage with an empty body and status code 400
>> >> >
>> >>
>> >> The client treats messages with an amqp-value sectioning containing
>> >> null/nothing as a TextMessage with null value if they arent annotated
>> >> to say otherwise, I'd guess thats where that comes from.
>> >>
>> >> >
>> >> > 2) Returned statusCode differs between Connector and Address
>> >> >
>> >> > Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
>> >> >
>> >> >
>> >> > * Connector operations return java.lang.Long
>> >> > * Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
>> >> >
>> >>
>> >> The router is presumably sending different values back for the
>> >> different operations here, a long and a uint. The router should
>> >> perhaps be consistent, and the client should perhaps not be returning
>> >> the uint object either way.
>> >>
>> >> The last draft of the management spec seems to say the status code
>> >> should be 'integer', im not clear if it means int (not uint)
>> >> specifically, or just any integral type value.
>> >>
>> >>
>> > The specification should definitely say which type should - so we'll fix
>> > that in the next draft. I'd suggest we should int (in AMQP terms) leading
>> > to a java.lang.Integer type in the property you see through Java.
>> >
>> > -- Rob
>> >
>> >
>> >
>> >> >
>> >> > 3) Create connector twice makes dispatch router crash. I don't have the
>> >> issue when creating addresses.
>> >> > On the second create call, JMS client receives a normal reply
>> >> containing a statusCode of an exception. After I close the connection to
>> >> the dispatch router via JMS (connection.close), I have the below crash
>> >> >
>> >> > (gdb) where
>> >> > #0 0x00007f27194448a5 in raise () from /lib64/libc.so.6
>> >> > #1 0x00007f2719446085 in abort () from /lib64/libc.so.6
>> >> > #2 0x00007f27194827b7 in __libc_message () from /lib64/libc.so.6
>> >> > #3 0x00007f27194880e6 in malloc_printerr () from /lib64/libc.so.6
>> >> > #4 0x00007f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf
>> >> expression opcode 0xf3
>> >> > ) at /qpid-dispatch-0.7.0/src/hash.c:320
>> >> > #5 0x00007f271a42247d in qdr_route_check_id_for_deletion_CT
>> >> (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
>> >> > ) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
>> >> > #6 0x00007f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30,
>> >> action=Unhandled dwarf expression opcode 0xf3
>> >> > ) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
>> >> > #7 0x00007f271a423f30 in router_core_thread (arg=0x13d2d30) at
>> >> /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
>> >> > #8 0x00007f2719f8c851 in start_thread () from /lib64/libpthread.so.0
>> >> > #9 0x00007f27194fa90d in clone () from /lib64/libc.so.6
>> >> >
>> >> >
>> >> > Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE:
>> >> org.apache.qpid.dispatch.connector: Duplicate value 'connector/
>> >> 127.0.0.1:5915:dispatch_management_connector_test' for unique attribute
>> >> 'identity'
>> >> > *** glibc detected *** /Dispatch/sbin/qdrouterd: double free or
>> >> corruption (fasttop): 0x00007f2708033f10 ***
>> >> > ======= Backtrace: =========
>> >> > /lib64/libc.so.6(+0x760e6)[0x7f27194880e6]
>> >> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>> >> .so(qd_hash_remove_by_handle+0x29)[0x7f271a40f109]
>> >> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>> >> .so(+0x3547d)[0x7f271a42247d]
>> >> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>> >> .so(+0x318d3)[0x7f271a41e8d3]
>> >> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>> >> .so(router_core_thread+0x230)[0x7f271a423f30]
>> >> > /lib64/libpthread.so.0(+0x7851)[0x7f2719f8c851]
>> >> > /lib64/libc.so.6(clone+0x6d)[0x7f27194fa90d]
>> >> > ======= Memory map: ========
>> >> > 00400000-00403000 r-xp 00000000 fd:01 7735642
>> >> /Dispatch/sbin/qdrouterd
>> >> > 00603000-00604000 rw-p 00003000 fd:01 7735642
>> >> /Dispatch/sbin/qdrouterd
>> >> > 01113000-01458000 rw-p 00000000 00:00 0
>> >> [heap]
>> >> > 7f26f8000000-7f26f805c000 rw-p 00000000 00:00 0
>> >> > 7f26f805c000-7f26fc000000 ---p 00000000 00:00 0
>> >> > 7f26fc000000-7f26fc043000 rw-p 00000000 00:00 0
>> >> > 7f26fc043000-7f2700000000 ---p 00000000 00:00 0
>> >> > 7f2700000000-7f2700085000 rw-p 00000000 00:00 0
>> >> > 7f2700085000-7f2704000000 ---p 00000000 00:00 0
>> >> > 7f27073e9000-7f27073ff000 r-xp 00000000 fd:00 524293
>> >> /lib64/libgcc_s-4.4.7-20120601.so.1
>> >> > 7f27073ff000-7f27075fe000 ---p 00016000 fd:00 524293
>> >> /lib64/libgcc_s-4.4.7-20120601.so.1
>> >> > 7f27075fe000-7f27075ff000 rw-p 00015000 fd:00 524293
>> >> /lib64/libgcc_s-4.4.7-20120601.so.1
>> >> > 7f27075ff000-7f2707600000 ---p 00000000 00:00 0
>> >> > 7f2707600000-7f2708000000 rw-p 00000000 00:00 0
>> >> > 7f2708000000-7f270805a000 rw-p 00000000 00:00 0
>> >> > 7f270805a000-7f270c000000 ---p 00000000 00:00 0
>> >> > 7f270c04a000-7f270c04f000 r-xp 00000000 fd:00 524322
>> >> /lib64/libnss_dns-2.12.so
>> >> > 7f270c04f000-7f270c24e000 ---p 00005000 fd:00 524322
>> >> /lib64/libnss_dns-2.12.so
>> >> > 7f270c24e000-7f270c24f000 r--p 00004000 fd:00 524322
>> >> /lib64/libnss_dns-2.12.so
>> >> > 7f270c24f000-7f270c250000 rw-p 00005000 fd:00 524322
>> >> /lib64/libnss_dns-2.12.so
>> >> > 7f270c250000-7f270c251000 ---p 00000000 00:00 0
>> >> > 7f270c251000-7f270cc51000 rw-p 00000000 00:00 0
>> >> > 7f270cc51000-7f270cc52000 ---p 00000000 00:00 0
>> >> > 7f270cc52000-7f270d652000 rw-p 00000000 00:00 0
>> >> > 7f270d652000-7f270d65e000 r-xp 00000000 fd:00 524324
>> >> /lib64/libnss_files-2.12.so
>> >> > 7f270d65e000-7f270d85e000 ---p 0000c000 fd:00 524324
>> >> /lib64/libnss_files-2.12.so
>> >> > 7f270d85e000-7f270d85f000 r--p 0000c000 fd:00 524324
>> >> /lib64/libnss_files-2.12.so
>> >> > 7f270d85f000-7f270d860000 rw-p 0000d000 fd:00 524324
>> >> /lib64/libnss_files-2.12.so
>> >> > 7f270d86a000-7f270d86b000 ---p 00000000 00:00 0
>> >> > 7f270d86b000-7f270e3ac000 rw-p 00000000 00:00 0
>> >> > 7f270e3ac000-7f270e3b1000 r-xp 00000000 00:16 4090944
>> >> /python278/lib/python2.7/lib-dynload/select.so
>> >> > 7f270e3b1000-7f270e5b0000 ---p 00005000 00:16 4090944
>> >> /python278/lib/python2.7/lib-dynload/select.so
>> >> > 7f270e5b0000-7f270e5b2000 rw-p 00004000 00:16 4090944
>> >> /python278/lib/python2.7/lib-dynload/select.so
>> >> > 7f270e5b2000-7f270e5b6000 r-xp 00000000 00:16 5568743
>> >> /python278/lib/python2.7/lib-dynload/_lsprof.so
>> >> > 7f270e5b6000-7f270e7b5000 ---p 00004000 00:16 5568743
>> >> /python278/lib/python2.7/lib-dynload/_lsprof.so
>> >> > 7f270e7b5000-7f270e7b6000 rw-p 00003000 00:16 5568743
>> >> /python278/lib/python2.7/lib-dynload/_lsprof.so
>> >> > 7f270e7b6000-7f270e8b7000 rw-p 00000000 00:00 0
>> >> > 7f270e8b7000-7f270e8bc000 r-xp 00000000 00:16 6394000
>> >> /python278/lib/python2.7/lib-dynload/strop.so
>> >> > 7f270e8bc000-7f270eabb000 ---p 00005000 00:16 6394000
>> >> /python278/lib/python2.7/lib-dynload/strop.so
>> >> > 7f270eabb000-7f270eabd000 rw-p 00004000 00:16 6394000
>> >> /python278/lib/python2.7/lib-dynload/strop.so
>> >> > 7f270eabd000-7f270eafd000 rw-p 00000000 00:00 0
>> >> > 7f270eafd000-7f270eb00000 r-xp 00000000 00:16 5568749
>> >> /python278/lib/python2.7/lib-dynload/fcntl.so
>> >> > 7f270eb00000-7f270ecff000 ---p 00003000 00:16 5568749
>> >> /python278/lib/python2.7/lib-dynload/fcntl.so
>> >> > 7f270ecff000-7f270ed01000 rw-p 00002000 00:16 5568749
>> >> /python278/lib/python2.7/lib-dynload/fcntl.so
>> >> > 7f270ed01000-7f270ed04000 r-xp 00000000 00:16 5568739
>> >> /python278/lib/python2.7/lib-dynload/_random.so
>> >> > 7f270ed04000-7f270ef03000 ---p 00003000 00:16 5568739
>> >> /python278/lib/python2.7/lib-dynload/_random.so
>> >> > 7f270ef03000-7f270ef04000 rw-p 00002000 00:16 5568739
>> >> /python278/lib/python2.7/lib-dynload/_random.so
>> >> > 4272 Aborted (core dumped)
>> >> >
>> >> >
>> >> > Regards,
>> >> > Adel
>> >> >
>> >> >
>> >> > ________________________________
>> >> > From: Rob Godfrey <ro...@gmail.com>
>> >> > Sent: Monday, February 6, 2017 7:09 PM
>> >> > To: users@qpid.apache.org
>> >> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>> >> >
>> >> > On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
>> >> > wrote:
>> >> >
>> >> >> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com>
>> >> wrote:
>> >> >> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
>> >> >> >
>> >> >> >> It seems odd that the client creates a _sender_ to the temporary
>> >> queue
>> >> >> >> that it will never send messages _to_ but will receive messages
>> >> _from_.
>> >> >> >>
>> >> >> >>
>> >> >> > This is because JMS semantics require the temporary node to have a
>> >> >> lifetime
>> >> >> > scoped to the session (not a link), so the JMS client has to create a
>> >> >> > synthetic link which it uses simply to manage the lifetime of the
>> >> dynamic
>> >> >> > node. In order to not cause unintentional assigning of messages to a
>> >> >> link
>> >> >> > that will never actually be used for consumption, a sending link is
>> >> used.
>> >> >> > Note that in general JMS would expect that you should be able to send
>> >> to
>> >> >> a
>> >> >> > temporary queue created in this way (since the point of temporary
>> >> queues
>> >> >> is
>> >> >> > to use as a reply to)
>> >> >> >
>> >> >>
>> >> >> Not really important here, but the lifetime is scoped to the
>> >> >> Connection, not Session (agghhh JMS... :P)
>> >> >>
>> >> >
>> >> > That's what I thought I was typing... obviously my fingers were not
>> >> > cooperating with my brain at that point :-)
>> >> >
>> >> > -- Rob
>> >> >
>> >> >
>> >> >>
>> >> >> >
>> >> >> >> Anyway, when the client creates a receiver with a dynamic source
>> >> (and no
>> >> >> >> dynamic-node-properties), the router will accept the link and assign
>> >> a
>> >> >> >> temporary address as the source. This is only useful in this use
>> >> case
>> >> >> if
>> >> >> >> the broker has a way of knowing that the temporary address is
>> >> reachable
>> >> >> via
>> >> >> >> the router network.
>> >> >> >>
>> >> >> >> There is a way to route dynamic termini to a broker. If an
>> >> >> >> x-opt-qd.address property is included in the
>> >> >> >> dynamic-node-properties,
>> >> >> this
>> >> >> >> address will be used to route the attach to the broker. I've never
>> >> >> tested
>> >> >> >> this with a dynamic target in a sender. It might not work.
>> >> >> >
>> >> >> >
>> >> >> > And this really isn't something you'd be expecting a generic client
>> >> (like
>> >> >> > the JMS client) to know :-)
>> >> >> >
>> >> >> > -- Rob
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> -Ted
>> >> >> >>
>> >> >> >>
>> >> >> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
>> >> >> >>
>> >> >> >>> I've had a look at this. It would seem that Dispatch doesn't like
>> >> what
>> >> >> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
>> >> >> >>> very nice way, and the client then doesnt notice that things have
>> >> gone
>> >> >> >>> south in a somewhat unexpected way.
>> >> >> >>>
>> >> >> >>> The client opens a sending link with 'dynamic' target in order to
>> >> >> >>> create a dynamic node for use as a TemporaryQueue
>> >> address/destination
>> >> >> >>> object, which specific consumers/producers are then created against
>> >> by
>> >> >> >>> the application. Dispatch doesn't seem to like that but erroneously
>> >> >> >>> attaches the link 'successfully', though doesnt set a target
>> >> >> >>> address
>> >> >> >>> as is expected. The client then doesnt notice this happened (its
>> >> >> >>> checking for the link being refused, which it wasn't), allowing the
>> >> >> >>> application to proceed as far as creating consumers/procuers using
>> >> the
>> >> >> >>> TemporaryQueue object, with creation of the e.g Consumer then
>> >> failing
>> >> >> >>> since the attach doesnt contain the needed information and leads to
>> >> >> >>> Dispatch detaching it with the error (though it again doesnt
>> >> actually
>> >> >> >>> indicate its refusing the link during the attach response, as it
>> >> >> >>> probably should have in this case).
>> >> >> >>>
>> >> >> >>> Making the client detect the current failure and having it throw an
>> >> >> >>> aexception from createTemporaryQueue is simple enough.
>> >> >> >>>
>> >> >> >>> Hacking the client to use a dynamic recieving link instead, an
>> >> address
>> >> >> >>> was returned by Dispatch in the attach response as expected,
>> >> however a
>> >> >> >>> consumer on the resulting TemporaryQueue object using this address
>> >> >> >>> still didnt get the message I sent to the same place. If I also
>> >> >> >>> gave
>> >> >> >>> some credit on the link backing the TemporaryQeueue object itself
>> >> then
>> >> >> >>> that link gets sent the message by Dispatch, though this of no use
>> >> for
>> >> >> >>> the JMS client.
>> >> >> >>>
>> >> >> >>> Needs some more investigation, and I'll need to discuss with some
>> >> >> >>> folks more familiar with Dispatch.
>> >> >> >>>
>> >> >> >>> Robbie
>> >> >> >>>
>> >> >> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
>> >> >> wrote:
>> >> >> >>>
>> >> >> >>>> Hello Robbie,
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the
>> >> reply
>> >> >> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS
>> >> Client.
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> PS: As Rabih stated before, we are using the same connection and
>> >> same
>> >> >> >>>> session to create the JMSProducer for the request and the
>> >> >> JMSConsumer for
>> >> >> >>>> the reply.
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> Exception
>> >> >> >>>> -------------------
>> >> >> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed
>> >> due
>> >> >> to
>> >> >> >>>> an unrecoverable error.
>> >> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
>> >> >> >>>> eConsumer.java:330)
>> >> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
>> >> >> >>>> sumer.java:196)
>> >> >> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
>> >> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> >> >> >>>> ssorImpl.java:62)
>> >> >> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> >> >> >>>> thodAccessorImpl.java:43)
>> >> >> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
>> >> >> >>>> at com.intellij.rt.execution.application.AppMain.main(
>> >> >> AppMain.java:147)
>> >> >> >>>> Caused by: javax.jms.JMSException: No route to the destination
>> >> >> >>>> node
>> >> >> >>>> [condition = qd:no-route-to-dest]
>> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>> >> >> >>>> tion(AmqpSupport.java:150)
>> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>> >> >> >>>> tion(AmqpSupport.java:105)
>> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
>> >> >> >>>> elyClosed(AmqpAbstractResource.java:147)
>> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
>> >> >> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
>> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
>> >> >> >>>> s(AmqpProvider.java:795)
>> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
>> >> >> >>>> mqpProvider.java:90)
>> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
>> >> >> >>>> ovider.java:699)
>> >> >> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
>> >> >> >>>> Executors.java:511)
>> >> >> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> >> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>> >> >> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>> >> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>> >> >> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
>> >> >> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> >> >> >>>> Executor.java:1142)
>> >> >> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> >> >> >>>> lExecutor.java:617)
>> >> >> >>>> at java.lang.Thread.run(Thread.java:745)
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> -------------------
>> >> >> >>>> Dispatch Router (PN_TRACE_FRM=1)
>> >> >> >>>> -------------------
>> >> >> >>>>
>> >> >> >>>> [832220]: <- SASL
>> >> >> >>>> [832220]: -> SASL
>> >> >> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
>> >> >> >>>> MBOL[:ANONYMOUS]]
>> >> >> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
>> >> >> >>>> initial-response=b"", hostname="host-name"]
>> >> >> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
>> >> >> >>>> [832220]: <- AMQP
>> >> >> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
>> >> >> a334-44c3-954a-2dd910161411:1",
>> >> >> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
>> >> >> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
>> >> >> >>>> L[:"sole-connection-for-container"],
>> >> properties={:product="QpidJMS",
>> >> >> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
>> >> >> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
>> >> >> >>>> [832220]: -> AMQP
>> >> >> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
>> >> >> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
>> >> >> >>>> offered-capabilities=:"ANONYMOUS-RELAY",
>> >> properties={:product="qpid-
>> >> >> dispatch-router",
>> >> >> >>>> :version="0.7.0"}]
>> >> >> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1,
>> >> >> >>>> incoming-window=2047,
>> >> >> >>>> outgoing-window=2147483647, handle-max=65535]
>> >> >> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
>> >> >> >>>> incoming-window=61, outgoing-window=2147483647]
>> >> >> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1,
>> >> >> >>>> incoming-window=2047,
>> >> >> >>>> outgoing-window=2147483647, handle-max=65535]
>> >> >> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
>> >> >> >>>> incoming-window=61, outgoing-window=2147483647]
>> >> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
>> >> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>> >> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
>> >> source=@source(40)
>> >> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
>> >> durable=0,
>> >> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>> >> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list",
>> >> :"amqp:rejected:list"]],
>> >> >> >>>> target=@target(41) [address="$management", durable=0,
>> >> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>> >> >> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
>> >> >> >>>> initial-delivery-count=0]
>> >> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
>> >> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>> >> >> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0,
>> >> >> >>>> source=@source(40)
>> >> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
>> >> durable=0,
>> >> >> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:acc
>> >> epted:list",
>> >> >> >>>> :"amqp:rejected:list"]], target=@target(41)
>> >> >> >>>> [address="$management",
>> >> >> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
>> >> >> queue]],
>> >> >> >>>> initial-delivery-count=0, max-message-size=0]
>> >> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>> >> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>> >> >> delivery-count=0,
>> >> >> >>>> link-credit=250, drain=false]
>> >> >> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
>> >> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
>> >> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
>> >> source=@source(40)
>> >> >> [],
>> >> >> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
>> >> >> timeout=0,
>> >> >> >>>> dynamic=true, dynamic-node-properties={:"lif
>> >> >> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
>> >> >> temporary-queue"]],
>> >> >> >>>> incomplete-unsettled=false, initial-delivery-count=0]
>> >> >> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
>> >> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
>> >> >> role=true,
>> >> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>> >> [durable=0,
>> >> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
>> >> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
>> >> >> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43)
>> >> []},
>> >> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
>> >> >> initial-delivery-count=0,
>> >> >> >>>> max-message-size=0]
>> >> >> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>> >> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>> >> >> delivery-count=0,
>> >> >> >>>> link-credit=250, drain=false]
>> >> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
>> >> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
>> >> role=true,
>> >> >> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
>> >> [durable=0,
>> >> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
>> >> >> >>>> default-outcome=@modified(39) [delivery-failed=true],
>> >> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
>> >> >> >>>> :"amqp:released:list", :"amqp:modified:list"],
>> >> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41)
>> >> []]
>> >> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
>> >> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
>> >> role=false,
>> >> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>> >> [durable=0,
>> >> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
>> >> timeout=0,
>> >> >> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
>> >> >> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
>> >> >> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
>> >> >> >>>> destination node"]]
>> >> >> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
>> >> >> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
>> >> >> delivery-tag=b"0",
>> >> >> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
>> >> >> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
>> >> >> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
>> >> >> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
>> >> >> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
>> >> >> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
>> >> >> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
>> >> >> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
>> >> >> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
>> >> >> >>>> x04addr\xa1\x0dbrokerMachine"
>> >> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
>> >> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>> >> >> delivery-count=1,
>> >> >> >>>> link-credit=250, drain=false]
>> >> >> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
>> >> >> >>>> settled=true, state=@accepted(36) []]
>> >> >> >>>> [832220]:0 <- @close(24) []
>> >> >> >>>> [832220]: <- EOS
>> >> >> >>>> [832220]:0 -> @close(24) []
>> >> >> >>>> [832220]: -> EOS
>> >> >> >>>> Closed x.x.x.x:8961
>> >> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
>> >> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
>> >> >> >>>>
>> >> >> >>>> ------------------
>> >> >> >>>> JMS Client (PN_TRACE_FRM=1)
>> >> >> >>>> ------------------
>> >> >> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
>> >> >> 4a22-9b22-69d27a017a83:1',
>> >> >> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
>> >> >> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
>> >> >> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
>> >> >> connection-for-container],
>> >> >> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM:
>> >> 1.8.0_111,
>> >> >> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
>> >> >> >>>> [1244186219:0] <- Open{ containerId='router.10200',
>> >> hostname='null',
>> >> >> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
>> >> >> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
>> >> >> ANONYMOUS-RELAY],
>> >> >> >>>> desiredCapabilities=null, properties={product=qpid-dispa
>> >> tch-router,
>> >> >> >>>> version=0.7.0}}
>> >> >> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
>> >> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> >> properties=null}
>> >> >> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
>> >> >> >>>> incomingWindow=61, outgoingWindow=2147483647,
>> >> >> >>>> handleMax=4294967295,
>> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> >> properties=null}
>> >> >> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
>> >> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> >> properties=null}
>> >> >> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
>> >> >> >>>> incomingWindow=61, outgoingWindow=2147483647,
>> >> >> >>>> handleMax=4294967295,
>> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> >> properties=null}
>> >> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
>> >> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
>> >> handle=0,
>> >> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>> >> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
>> >> >> 3293ffc57168:1:1:1',
>> >> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>> >> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
>> >> >> amqp:rejected:list],
>> >> >> >>>> capabilities=null}, target=Target{address='$management',
>> >> >> durable=NONE,
>> >> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>> >> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> >> >> maxMessageSize=null,
>> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> >> properties=null}
>> >> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
>> >> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
>> >> handle=0,
>> >> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>> >> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
>> >> >> 3293ffc57168:1:1:1',
>> >> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>> >> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
>> >> >> amqp:rejected:list],
>> >> >> >>>> capabilities=null}, target=Target{address='$management',
>> >> >> durable=NONE,
>> >> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>> >> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> >> maxMessageSize=0,
>> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> >> properties=null}
>> >> >> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
>> >> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>> >> >> deliveryCount=0,
>> >> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
>> >> >> properties=null}
>> >> >> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
>> >> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>> >> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>> >> >> >>>> source=Source{address='null', durable=NONE,
>> >> expiryPolicy=SESSION_END,
>> >> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>> >> >> outcomes=null,
>> >> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>> >> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>> >> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>> >> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
>> >> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> >> >> maxMessageSize=null,
>> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> >> properties=null}
>> >> >> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
>> >> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>> >> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>> >> >> >>>> source=Source{address='null', durable=NONE,
>> >> expiryPolicy=SESSION_END,
>> >> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>> >> >> outcomes=null,
>> >> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>> >> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>> >> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>> >> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
>> >> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> >> maxMessageSize=0,
>> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> >> properties=null}
>> >> >> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
>> >> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>> >> >> deliveryCount=0,
>> >> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
>> >> >> properties=null}
>> >> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
>> >> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>> >> >> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>> >> >> >>>> source=Source{address='null', durable=NONE,
>> >> expiryPolicy=LINK_DETACH,
>> >> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> >> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
>> >> >> deliveryFailed=true,
>> >> >> >>>> undeliverableHere=null, messageAnnotations=null},
>> >> >> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list,
>> >> amqp:released:list,
>> >> >> >>>> amqp:modified:list], capabilities=[temporary-queue]},
>> >> >> >>>> target=Target{address='null', durable=NONE,
>> >> expiryPolicy=SESSION_END,
>> >> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> >> capabilities=null},
>> >> >> >>>> unsettled=null, incompleteUnsettled=false,
>> >> initialDeliveryCount=null,
>> >> >> >>>> maxMessageSize=null, offeredCapabilities=null,
>> >> >> desiredCapabilities=null,
>> >> >> >>>> properties=null}
>> >> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
>> >> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>> >> >> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>> >> >> >>>> source=Source{address='null', durable=NONE,
>> >> expiryPolicy=SESSION_END,
>> >> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>> >> >> outcomes=null,
>> >> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>> >> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
>> >> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> >> maxMessageSize=0,
>> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> >> properties=null}
>> >> >> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
>> >> >> >>>> error=Error{condition=qd:no-route-to-dest, description='No route
>> >> to
>> >> >> the
>> >> >> >>>> destination node', info=null}}
>> >> >> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
>> >> >> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
>> >> >> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
>> >> >> state=null,
>> >> >> >>>> resume=false, aborted=false, batchable=false} (312)
>> >> >> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
>> >> >> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
>> >> >> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$man
>> >> agement@
>> >> >> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
>> >> >> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
>> >> >> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
>> >> >> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
>> >> >> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
>> >> >> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
>> >> >> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
>> >> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>> >> >> deliveryCount=1,
>> >> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
>> >> >> properties=null}
>> >> >> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
>> >> >> >>>> settled=true, state=Accepted{}, batchable=false}
>> >> >> >>>> [1244186219:0] -> Close{error=null}
>> >> >> >>>> [1244186219:0] <- Close{error=null}
>> >> >> >>>>
>> >> >> >>>> Regards,
>> >> >> >>>>
>> >> >> >>>> Adel
>> >> >> >>>>
>> >> >> >>>> ________________________________
>> >> >> >>>> From: Robbie Gemmell <ro...@gmail.com>
>> >> >> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
>> >> >> >>>> To: users@qpid.apache.org
>> >> >> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>> >> >> >>>>
>> >> >> >>>> That looks fine at first glance. Its possible there is an issue in
>> >> >> >>>> there needing looked it. I am travelling this week so may not get
>> >> to
>> >> >> >>>> look until afterwards, but will try to give things a look at. If
>> >> you
>> >> >> >>>> could give more detail on the exception and maybe a protocol trace
>> >> >> >>>> that might be useful.
>> >> >> >>>>
>> >> >> >>>> Robbie
>> >> >> >>>>
>> >> >> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com>
>> >> wrote:
>> >> >> >>>>
>> >> >> >>>>> Hello Robbie,
>> >> >> >>>>>
>> >> >> >>>>> Thanks for you for your answer.
>> >> >> >>>>> I will try the solutions you proposed.
>> >> >> >>>>>
>> >> >> >>>>> I need just need one clarification. Concerning the Jms, I already
>> >> >> tried
>> >> >> >>>>> to
>> >> >> >>>>> use a temporary queue but it didn't work. May be i am using it
>> >> wrong.
>> >> >> >>>>> Here
>> >> >> >>>>> is what i did:
>> >> >> >>>>>
>> >> >> >>>>> ...
>> >> >> >>>>> Session session = connection.createSession(false,
>> >> >> >>>>> Session.AUTO_ACKNOWLEDGE);
>> >> >> >>>>> Queue queue = session.createQueue("$management");
>> >> >> >>>>> MessageProducer producer = session.createProducer(queue);
>> >> >> >>>>>
>> >> >> >>>>> Queue tempDest = session.createTemporaryQueue();
>> >> >> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDes
>> >> t);
>> >> >> >>>>> connection.start();
>> >> >> >>>>>
>> >> >> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
>> >> >> >>>>> objectMessage.setJMSReplyTo(tempDest);
>> >> >> >>>>> //fill the rest of the parameters ...
>> >> >> >>>>> producer.send(objectMessage);
>> >> >> >>>>> ObjectMessage replyMessage = (ObjectMessage)
>> >> >> >>>>> responseConsumer.receive(1000);
>> >> >> >>>>> ...
>> >> >> >>>>>
>> >> >> >>>>> I was getting an exception on the .receive() from the dispatch
>> >> router
>> >> >> >>>>> saying that the reply-to address is bad...
>> >> >> >>>>> Should i create the temporary queue and the consumer from a
>> >> different
>> >> >> >>>>> session then the producer?
>> >> >> >>>>>
>> >> >> >>>>> Best regards,
>> >> >> >>>>> Rabih
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
>> >> >> >>>>> robbie.gemmell@gmail.com>
>> >> >> >>>>> wrote:
>> >> >> >>>>>
>> >> >> >>>>> The session.createTemporaryQueue(); method is how JMS creates
>> >> >> >>>>>> temporary destinations for use in reply-to scenarios. The
>> >> dispatch
>> >> >> >>>>>> tools will be doing essentially the same thing under the covers
>> >> for
>> >> >> >>>>>> theirs.
>> >> >> >>>>>>
>> >> >> >>>>>> Both work by creating a 'dynamic' link attachment, with the
>> >> server
>> >> >> >>>>>> returning an address for the dynamic attach to the client. One
>> >> key
>> >> >> >>>>>> difference is with JMS you create the temporary destination (for
>> >> >> which
>> >> >> >>>>>> the client uses a dynamic sender link to create), then
>> >> >> >>>>>> separately
>> >> >> >>>>>> create a receiver using it (and in turn the address associated
>> >> with
>> >> >> >>>>>> it), whereas non-JMS client/tools will typically just create a
>> >> >> single
>> >> >> >>>>>> dynamic receiver link and use its address for the reply-to.
>> >> >> >>>>>>
>> >> >> >>>>>> For proton-j, there aren't any examples for this, but you you
>> >> >> >>>>>> essentially would change the link opening to not specify an
>> >> address,
>> >> >> >>>>>> and instead set the source(for a receiver) or target (for a
>> >> sender)
>> >> >> to
>> >> >> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
>> >> >> remoteTarget
>> >> >> >>>>>> once the link had been reemotely attached, and get its
>> >> >> >>>>>> (server-generated) address, then use this as your reply-to.
>> >> >> >>>>>>
>> >> >> >>>>>> Robbie
>> >> >> >>>>>>
>> >> >> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
>> >> >> wrote:
>> >> >> >>>>>>
>> >> >> >>>>>>> Hello,
>> >> >> >>>>>>>
>> >> >> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like
>> >> you
>> >> >> >>>>>>> suggested, it worked.
>> >> >> >>>>>>> But I cheated a little to make it work because I did not find a
>> >> >> way in
>> >> >> >>>>>>>
>> >> >> >>>>>> JMS
>> >> >> >>>>>>
>> >> >> >>>>>>> to create a local queue. So I created a queue on the
>> >> qpid-dispatch
>> >> >> and
>> >> >> >>>>>>>
>> >> >> >>>>>> read
>> >> >> >>>>>>
>> >> >> >>>>>>> the result from it. You can check the attached code.
>> >> >> >>>>>>>
>> >> >> >>>>>>> Is there any way using qpid-jms to create a local queue on the
>> >> >> client
>> >> >> >>>>>>>
>> >> >> >>>>>> side
>> >> >> >>>>>>
>> >> >> >>>>>>> to serve as a reply to address?
>> >> >> >>>>>>>
>> >> >> >>>>>>> For the proton-j test, I have the same question as above. I saw
>> >> >> that
>> >> >> >>>>>>> it
>> >> >> >>>>>>>
>> >> >> >>>>>> can
>> >> >> >>>>>>
>> >> >> >>>>>>> be done with the C++ API. Are there any examples for proton-j
>> >> >> >>>>>>> or
>> >> >> >>>>>>>
>> >> >> >>>>>> something
>> >> >> >>>>>>
>> >> >> >>>>>>> that can help me?
>> >> >> >>>>>>>
>> >> >> >>>>>>> I saw may be in proton we don't need a local queue, may be we
>> >> can
>> >> >> get
>> >> >> >>>>>>> the
>> >> >> >>>>>>> address of the consumer directly and pass it in reply-to field.
>> >> Is
>> >> >> it
>> >> >> >>>>>>> correct?
>> >> >> >>>>>>>
>> >> >> >>>>>>> Thanks,
>> >> >> >>>>>>> Rabih
>> >> >> >>>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
>> >> >> >>>>>>> rob.j.godfrey@gmail.com>
>> >> >> >>>>>>> wrote:
>> >> >> >>>>>>>
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gmurthy@redhat.com
>> >> >
>> >> >> >>>>>>>> wrote:
>> >> >> >>>>>>>>
>> >> >> >>>>>>>>
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>> ----- Original Message -----
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
>> >> >> >>>>>>>>>> To: users@qpid.apache.org
>> >> >> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
>> >> >> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from
>> >> >> >>>>>>>>>> Qpid
>> >> >> Jms
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
>> >> >> wrote:
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like
>> >> >> >>>>>>>>>>>> you
>> >> >> told
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>> me
>> >> >> >>>>>>
>> >> >> >>>>>>> Robbie and it worked.
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> But like the proton-j case, the connector is not being
>> >> >> created on
>> >> >> >>>>>>>>>>>> the
>> >> >> >>>>>>>>>>>> Qpid-dispatch side.
>> >> >> >>>>>>>>>>>> I attached the amqp communication into this mail.
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> The last frame in that file is incomplete (the previous
>> >> error
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>> regarding the
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
>> >> >> frame
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>> is
>> >> >> >>>>>>
>> >> >> >>>>>>> likely
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>> the response which would indicate the success or otherwise
>> >> >> >>>>>>>>>> of
>> >> >> the
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>> frame. Is
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>> there anything logged by the router?
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
>> >> >> simpler
>> >> >> >>>>>>>>>>> for
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>> this
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>> sort of thing in my view.
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more
>> >> helpful.
>> >> >> >>>>>>>>>> You
>> >> >> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
>> >> >> since
>> >> >> >>>>>>>>>> it
>> >> >> >>>>>>>>>> uses proton-j.
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>> One key difference from the qdmanage case is you are not
>> >> >> setting a
>> >> >> >>>>>>>>>> reply-to value or correlation-id to use along with it. I
>> >> don't
>> >> >> know
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>> if
>> >> >> >>>>>>
>> >> >> >>>>>>> the router cares about not being able to send a response or not
>> >> >> >>>>>>>>>> though, but it might.
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>> You could add the following to your dispatch router conf file
>> >> >> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable
>> >> trace
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>> logging)
>> >> >> >>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>>>> log {
>> >> >> >>>>>>>>> module: DEFAULT
>> >> >> >>>>>>>>> enable: trace+
>> >> >> >>>>>>>>> output: /path/to/log/qdrouterd.log
>> >> >> >>>>>>>>> }
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>> When you run your management request, you will see proton
>> >> frame
>> >> >> >>>>>>>>> trace
>> >> >> >>>>>>>>> and
>> >> >> >>>>>>>>> you will see additional logging out of the dispatch Python
>> >> agent
>> >> >> -
>> >> >> >>>>>>>>> something like the following -
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>> >> >> >>>>>>>>> Message(address=None,
>> >> >> >>>>>>>>> properties={'operation': 'CREATE', 'type':
>> >> >> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
>> >> >> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>> >> >> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>> 'rabih.connector'},
>> >> >> >>>>>>
>> >> >> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>> >> >> >>>>>>>>> correlation_id=1L)
>> >> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured
>> >> >> >>>>>>>>> Connector:
>> >> >> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
>> >> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>> >> >> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True,
>> >> cost=1,
>> >> >> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
>> >> >> 5673:rabih.connector,
>> >> >> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>> >> >> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
>> >> >> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.
>> >> connector,
>> >> >> >>>>>>>>> verifyHostName=True)
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>> The Python management agent will not process your request if
>> >> >> there
>> >> >> >>>>>>>>> is
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>> no
>> >> >> >>>>>>
>> >> >> >>>>>>> reply_to as seen here -
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
>> >> >> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
>> >> >> because
>> >> >> >>>>>>>> there
>> >> >> >>>>>>>> is
>> >> >> >>>>>>>> a reply-to doesn't mean that the sender will be around to
>> >> actually
>> >> >> >>>>>>>> hear
>> >> >> >>>>>>>> the
>> >> >> >>>>>>>> reply, so it seems a bit arbitrary to say that because we
>> >> *know*
>> >> >> the
>> >> >> >>>>>>>> sender
>> >> >> >>>>>>>> won't learn of the outcome that we won't do anything... The
>> >> spec
>> >> >> >>>>>>>> draft
>> >> >> >>>>>>>> doesn't currently say anything about this (obviously it should
>> >> >> do),
>> >> >> >>>>>>>> but
>> >> >> >>>>>>>>
>> >> >> >>>>>>> my
>> >> >> >>>>>>
>> >> >> >>>>>>> expectation would certainly be that a request would be
>> >> >> >>>>>>> processed
>> >> >> even
>> >> >> >>>>>>>> if
>> >> >> >>>>>>>> the replyTo address was not present (or ended up not routing
>> >> >> >>>>>>>> anywhere).
>> >> >> >>>>>>>> This is also how the Qpid Broker for Java implements this
>> >> >> >>>>>>>> case.
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> -- Rob
>> >> >> >>>>>>>>
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> Thanks.
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>> Robbie
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>> ------------------------------------------------------------
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>> ---------
>> >> >> >>>>>>
>> >> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>> ------------------------------------------------------------
>> >> >> >>>>>>>>> ---------
>> >> >> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>> ------------------------------------------------------------
>> >> >> ---------
>> >> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >> >>>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>> ------------------------------------------------------------
>> >> >> ---------
>> >> >> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>> ------------------------------------------------------------
>> >> ---------
>> >> >> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >> >>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>> ------------------------------------------------------------
>> >> ---------
>> >> >> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >> >>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >> >>>
>> >> >> >>>
>> >> >> >> ------------------------------------------------------------
>> >> ---------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >> >> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>
>> >> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> For additional commands, e-mail: users-help@qpid.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Ganesh Murthy <gm...@redhat.com>.
Hi Robbie,
----- Original Message -----
> From: "Robbie Gemmell" <ro...@gmail.com>
> To: users@qpid.apache.org
> Sent: Friday, February 24, 2017 11:43:05 AM
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> I tried this (modified to use a temporary queue) and also modified the
> Qpid JMS HelloWorld example to use a temporary queue, and ran both
> against the router successfully multiple times, using the jms client
> from master, dispatch from master, and proton from master.
>
> The only odd thing was that Dispatch printed out two copies of notices
> about the connection closing without the links being explicitly
> detached, which is what the examples do and not something I would
> consider unusual. I wouldnt really expect to see these notices, but if
> so then only one copy.
>
> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
> due to parent connection end
> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
> due to parent connection end
> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
> due to parent connection end
> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
> due to parent connection end
> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
> due to parent connection end
> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
> due to parent connection end
>
These log messages should not appear in the case of running the Qpid JMS Hello World examples. These are supposed to appear only
when a socket close is received. I have entered a JIRA for this -
https://issues.apache.org/jira/browse/DISPATCH-643
I have fixed this issue on master branch.
Thanks much.
> As an aside, the typical TemporaryQueue usage would be just to use the
> destination object directly, i.e the below, not ask its name and
> create another destination with that name. I tried both ways just to
> check it wasnt related though and they both worked the same.
> TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
> managementConsumer = managementSession.createConsumer(temporaryQueue);
>
>
> On 22 February 2017 at 11:33, Adel Boutros <Ad...@live.com> wrote:
> > Hello guys,
> >
> >
> > My basic JMS API is almost ready. I will share it with you soon to have
> > your feedback.
> >
> >
> > However, I tried one last thing by getting a random queue name and using it
> > as management reply queue to allow multiple configuration sessions
> > simultaneously but it didn't work.
> >
> >
> > //This doesn't work and crashes the dispatch router
> >
> > TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
> > replyToQueue =
> > managementSession.createQueue(temporaryQueue.getQueueName());
> > managementConsumer = managementSession.createConsumer(replyToQueue);
> >
> > //This is the only thing working
> > replyToQueue = managementSession.createQueue("HARD_CODED_REPLY_QUEUE");
> > managementConsumer = managementSession.createConsumer(replyToQueue);
> >
> >
> > Can I have your input on the above?
> >
> > Regards,
> > Adel
> >
> >
> > ________________________________
> > From: Rob Godfrey <ro...@gmail.com>
> > Sent: Wednesday, February 15, 2017 4:46:59 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >
> > On 15 February 2017 at 16:07, Robbie Gemmell <ro...@gmail.com>
> > wrote:
> >
> >> On 15 February 2017 at 14:15, Adel Boutros <Ad...@live.com> wrote:
> >> > Hello guys,
> >> >
> >> >
> >> > Based on the discussion, we are currently writing a Java API based on
> >> JMS to configure the dispatch router. I have so far managed to do the
> >> following:
> >> >
> >> > * Create, Read, Delete addresses
> >> >
> >> > * Create, Read, Delete connectors
> >> >
> >> >
> >> > Config:
> >> >
> >> > Dispatch Router 0.7.0
> >> >
> >> > JMS 0.11.1
> >> >
> >> >
> >> > And I have noticed some problems and differences:
> >> >
> >> >
> >> > 1) It seems some calls return ObjectMessage and some TextMessage (This
> >> is on the side of the consumer in the replyTo)
> >> >
> >> > For example, creating twice the same queue will fail but the second call
> >> will return a JmsTextMessage with an empty body and status code 400
> >> >
> >>
> >> The client treats messages with an amqp-value sectioning containing
> >> null/nothing as a TextMessage with null value if they arent annotated
> >> to say otherwise, I'd guess thats where that comes from.
> >>
> >> >
> >> > 2) Returned statusCode differs between Connector and Address
> >> >
> >> > Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
> >> >
> >> >
> >> > * Connector operations return java.lang.Long
> >> > * Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
> >> >
> >>
> >> The router is presumably sending different values back for the
> >> different operations here, a long and a uint. The router should
> >> perhaps be consistent, and the client should perhaps not be returning
> >> the uint object either way.
> >>
> >> The last draft of the management spec seems to say the status code
> >> should be 'integer', im not clear if it means int (not uint)
> >> specifically, or just any integral type value.
> >>
> >>
> > The specification should definitely say which type should - so we'll fix
> > that in the next draft. I'd suggest we should int (in AMQP terms) leading
> > to a java.lang.Integer type in the property you see through Java.
> >
> > -- Rob
> >
> >
> >
> >> >
> >> > 3) Create connector twice makes dispatch router crash. I don't have the
> >> issue when creating addresses.
> >> > On the second create call, JMS client receives a normal reply
> >> containing a statusCode of an exception. After I close the connection to
> >> the dispatch router via JMS (connection.close), I have the below crash
> >> >
> >> > (gdb) where
> >> > #0 0x00007f27194448a5 in raise () from /lib64/libc.so.6
> >> > #1 0x00007f2719446085 in abort () from /lib64/libc.so.6
> >> > #2 0x00007f27194827b7 in __libc_message () from /lib64/libc.so.6
> >> > #3 0x00007f27194880e6 in malloc_printerr () from /lib64/libc.so.6
> >> > #4 0x00007f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf
> >> expression opcode 0xf3
> >> > ) at /qpid-dispatch-0.7.0/src/hash.c:320
> >> > #5 0x00007f271a42247d in qdr_route_check_id_for_deletion_CT
> >> (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
> >> > ) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
> >> > #6 0x00007f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30,
> >> action=Unhandled dwarf expression opcode 0xf3
> >> > ) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
> >> > #7 0x00007f271a423f30 in router_core_thread (arg=0x13d2d30) at
> >> /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
> >> > #8 0x00007f2719f8c851 in start_thread () from /lib64/libpthread.so.0
> >> > #9 0x00007f27194fa90d in clone () from /lib64/libc.so.6
> >> >
> >> >
> >> > Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE:
> >> org.apache.qpid.dispatch.connector: Duplicate value 'connector/
> >> 127.0.0.1:5915:dispatch_management_connector_test' for unique attribute
> >> 'identity'
> >> > *** glibc detected *** /Dispatch/sbin/qdrouterd: double free or
> >> corruption (fasttop): 0x00007f2708033f10 ***
> >> > ======= Backtrace: =========
> >> > /lib64/libc.so.6(+0x760e6)[0x7f27194880e6]
> >> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> >> .so(qd_hash_remove_by_handle+0x29)[0x7f271a40f109]
> >> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> >> .so(+0x3547d)[0x7f271a42247d]
> >> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> >> .so(+0x318d3)[0x7f271a41e8d3]
> >> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> >> .so(router_core_thread+0x230)[0x7f271a423f30]
> >> > /lib64/libpthread.so.0(+0x7851)[0x7f2719f8c851]
> >> > /lib64/libc.so.6(clone+0x6d)[0x7f27194fa90d]
> >> > ======= Memory map: ========
> >> > 00400000-00403000 r-xp 00000000 fd:01 7735642
> >> /Dispatch/sbin/qdrouterd
> >> > 00603000-00604000 rw-p 00003000 fd:01 7735642
> >> /Dispatch/sbin/qdrouterd
> >> > 01113000-01458000 rw-p 00000000 00:00 0
> >> [heap]
> >> > 7f26f8000000-7f26f805c000 rw-p 00000000 00:00 0
> >> > 7f26f805c000-7f26fc000000 ---p 00000000 00:00 0
> >> > 7f26fc000000-7f26fc043000 rw-p 00000000 00:00 0
> >> > 7f26fc043000-7f2700000000 ---p 00000000 00:00 0
> >> > 7f2700000000-7f2700085000 rw-p 00000000 00:00 0
> >> > 7f2700085000-7f2704000000 ---p 00000000 00:00 0
> >> > 7f27073e9000-7f27073ff000 r-xp 00000000 fd:00 524293
> >> /lib64/libgcc_s-4.4.7-20120601.so.1
> >> > 7f27073ff000-7f27075fe000 ---p 00016000 fd:00 524293
> >> /lib64/libgcc_s-4.4.7-20120601.so.1
> >> > 7f27075fe000-7f27075ff000 rw-p 00015000 fd:00 524293
> >> /lib64/libgcc_s-4.4.7-20120601.so.1
> >> > 7f27075ff000-7f2707600000 ---p 00000000 00:00 0
> >> > 7f2707600000-7f2708000000 rw-p 00000000 00:00 0
> >> > 7f2708000000-7f270805a000 rw-p 00000000 00:00 0
> >> > 7f270805a000-7f270c000000 ---p 00000000 00:00 0
> >> > 7f270c04a000-7f270c04f000 r-xp 00000000 fd:00 524322
> >> /lib64/libnss_dns-2.12.so
> >> > 7f270c04f000-7f270c24e000 ---p 00005000 fd:00 524322
> >> /lib64/libnss_dns-2.12.so
> >> > 7f270c24e000-7f270c24f000 r--p 00004000 fd:00 524322
> >> /lib64/libnss_dns-2.12.so
> >> > 7f270c24f000-7f270c250000 rw-p 00005000 fd:00 524322
> >> /lib64/libnss_dns-2.12.so
> >> > 7f270c250000-7f270c251000 ---p 00000000 00:00 0
> >> > 7f270c251000-7f270cc51000 rw-p 00000000 00:00 0
> >> > 7f270cc51000-7f270cc52000 ---p 00000000 00:00 0
> >> > 7f270cc52000-7f270d652000 rw-p 00000000 00:00 0
> >> > 7f270d652000-7f270d65e000 r-xp 00000000 fd:00 524324
> >> /lib64/libnss_files-2.12.so
> >> > 7f270d65e000-7f270d85e000 ---p 0000c000 fd:00 524324
> >> /lib64/libnss_files-2.12.so
> >> > 7f270d85e000-7f270d85f000 r--p 0000c000 fd:00 524324
> >> /lib64/libnss_files-2.12.so
> >> > 7f270d85f000-7f270d860000 rw-p 0000d000 fd:00 524324
> >> /lib64/libnss_files-2.12.so
> >> > 7f270d86a000-7f270d86b000 ---p 00000000 00:00 0
> >> > 7f270d86b000-7f270e3ac000 rw-p 00000000 00:00 0
> >> > 7f270e3ac000-7f270e3b1000 r-xp 00000000 00:16 4090944
> >> /python278/lib/python2.7/lib-dynload/select.so
> >> > 7f270e3b1000-7f270e5b0000 ---p 00005000 00:16 4090944
> >> /python278/lib/python2.7/lib-dynload/select.so
> >> > 7f270e5b0000-7f270e5b2000 rw-p 00004000 00:16 4090944
> >> /python278/lib/python2.7/lib-dynload/select.so
> >> > 7f270e5b2000-7f270e5b6000 r-xp 00000000 00:16 5568743
> >> /python278/lib/python2.7/lib-dynload/_lsprof.so
> >> > 7f270e5b6000-7f270e7b5000 ---p 00004000 00:16 5568743
> >> /python278/lib/python2.7/lib-dynload/_lsprof.so
> >> > 7f270e7b5000-7f270e7b6000 rw-p 00003000 00:16 5568743
> >> /python278/lib/python2.7/lib-dynload/_lsprof.so
> >> > 7f270e7b6000-7f270e8b7000 rw-p 00000000 00:00 0
> >> > 7f270e8b7000-7f270e8bc000 r-xp 00000000 00:16 6394000
> >> /python278/lib/python2.7/lib-dynload/strop.so
> >> > 7f270e8bc000-7f270eabb000 ---p 00005000 00:16 6394000
> >> /python278/lib/python2.7/lib-dynload/strop.so
> >> > 7f270eabb000-7f270eabd000 rw-p 00004000 00:16 6394000
> >> /python278/lib/python2.7/lib-dynload/strop.so
> >> > 7f270eabd000-7f270eafd000 rw-p 00000000 00:00 0
> >> > 7f270eafd000-7f270eb00000 r-xp 00000000 00:16 5568749
> >> /python278/lib/python2.7/lib-dynload/fcntl.so
> >> > 7f270eb00000-7f270ecff000 ---p 00003000 00:16 5568749
> >> /python278/lib/python2.7/lib-dynload/fcntl.so
> >> > 7f270ecff000-7f270ed01000 rw-p 00002000 00:16 5568749
> >> /python278/lib/python2.7/lib-dynload/fcntl.so
> >> > 7f270ed01000-7f270ed04000 r-xp 00000000 00:16 5568739
> >> /python278/lib/python2.7/lib-dynload/_random.so
> >> > 7f270ed04000-7f270ef03000 ---p 00003000 00:16 5568739
> >> /python278/lib/python2.7/lib-dynload/_random.so
> >> > 7f270ef03000-7f270ef04000 rw-p 00002000 00:16 5568739
> >> /python278/lib/python2.7/lib-dynload/_random.so
> >> > 4272 Aborted (core dumped)
> >> >
> >> >
> >> > Regards,
> >> > Adel
> >> >
> >> >
> >> > ________________________________
> >> > From: Rob Godfrey <ro...@gmail.com>
> >> > Sent: Monday, February 6, 2017 7:09 PM
> >> > To: users@qpid.apache.org
> >> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >> >
> >> > On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
> >> > wrote:
> >> >
> >> >> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com>
> >> wrote:
> >> >> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
> >> >> >
> >> >> >> It seems odd that the client creates a _sender_ to the temporary
> >> queue
> >> >> >> that it will never send messages _to_ but will receive messages
> >> _from_.
> >> >> >>
> >> >> >>
> >> >> > This is because JMS semantics require the temporary node to have a
> >> >> lifetime
> >> >> > scoped to the session (not a link), so the JMS client has to create a
> >> >> > synthetic link which it uses simply to manage the lifetime of the
> >> dynamic
> >> >> > node. In order to not cause unintentional assigning of messages to a
> >> >> link
> >> >> > that will never actually be used for consumption, a sending link is
> >> used.
> >> >> > Note that in general JMS would expect that you should be able to send
> >> to
> >> >> a
> >> >> > temporary queue created in this way (since the point of temporary
> >> queues
> >> >> is
> >> >> > to use as a reply to)
> >> >> >
> >> >>
> >> >> Not really important here, but the lifetime is scoped to the
> >> >> Connection, not Session (agghhh JMS... :P)
> >> >>
> >> >
> >> > That's what I thought I was typing... obviously my fingers were not
> >> > cooperating with my brain at that point :-)
> >> >
> >> > -- Rob
> >> >
> >> >
> >> >>
> >> >> >
> >> >> >> Anyway, when the client creates a receiver with a dynamic source
> >> (and no
> >> >> >> dynamic-node-properties), the router will accept the link and assign
> >> a
> >> >> >> temporary address as the source. This is only useful in this use
> >> case
> >> >> if
> >> >> >> the broker has a way of knowing that the temporary address is
> >> reachable
> >> >> via
> >> >> >> the router network.
> >> >> >>
> >> >> >> There is a way to route dynamic termini to a broker. If an
> >> >> >> x-opt-qd.address property is included in the
> >> >> >> dynamic-node-properties,
> >> >> this
> >> >> >> address will be used to route the attach to the broker. I've never
> >> >> tested
> >> >> >> this with a dynamic target in a sender. It might not work.
> >> >> >
> >> >> >
> >> >> > And this really isn't something you'd be expecting a generic client
> >> (like
> >> >> > the JMS client) to know :-)
> >> >> >
> >> >> > -- Rob
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> -Ted
> >> >> >>
> >> >> >>
> >> >> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
> >> >> >>
> >> >> >>> I've had a look at this. It would seem that Dispatch doesn't like
> >> what
> >> >> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
> >> >> >>> very nice way, and the client then doesnt notice that things have
> >> gone
> >> >> >>> south in a somewhat unexpected way.
> >> >> >>>
> >> >> >>> The client opens a sending link with 'dynamic' target in order to
> >> >> >>> create a dynamic node for use as a TemporaryQueue
> >> address/destination
> >> >> >>> object, which specific consumers/producers are then created against
> >> by
> >> >> >>> the application. Dispatch doesn't seem to like that but erroneously
> >> >> >>> attaches the link 'successfully', though doesnt set a target
> >> >> >>> address
> >> >> >>> as is expected. The client then doesnt notice this happened (its
> >> >> >>> checking for the link being refused, which it wasn't), allowing the
> >> >> >>> application to proceed as far as creating consumers/procuers using
> >> the
> >> >> >>> TemporaryQueue object, with creation of the e.g Consumer then
> >> failing
> >> >> >>> since the attach doesnt contain the needed information and leads to
> >> >> >>> Dispatch detaching it with the error (though it again doesnt
> >> actually
> >> >> >>> indicate its refusing the link during the attach response, as it
> >> >> >>> probably should have in this case).
> >> >> >>>
> >> >> >>> Making the client detect the current failure and having it throw an
> >> >> >>> aexception from createTemporaryQueue is simple enough.
> >> >> >>>
> >> >> >>> Hacking the client to use a dynamic recieving link instead, an
> >> address
> >> >> >>> was returned by Dispatch in the attach response as expected,
> >> however a
> >> >> >>> consumer on the resulting TemporaryQueue object using this address
> >> >> >>> still didnt get the message I sent to the same place. If I also
> >> >> >>> gave
> >> >> >>> some credit on the link backing the TemporaryQeueue object itself
> >> then
> >> >> >>> that link gets sent the message by Dispatch, though this of no use
> >> for
> >> >> >>> the JMS client.
> >> >> >>>
> >> >> >>> Needs some more investigation, and I'll need to discuss with some
> >> >> >>> folks more familiar with Dispatch.
> >> >> >>>
> >> >> >>> Robbie
> >> >> >>>
> >> >> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
> >> >> wrote:
> >> >> >>>
> >> >> >>>> Hello Robbie,
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the
> >> reply
> >> >> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS
> >> Client.
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> PS: As Rabih stated before, we are using the same connection and
> >> same
> >> >> >>>> session to create the JMSProducer for the request and the
> >> >> JMSConsumer for
> >> >> >>>> the reply.
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Exception
> >> >> >>>> -------------------
> >> >> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed
> >> due
> >> >> to
> >> >> >>>> an unrecoverable error.
> >> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
> >> >> >>>> eConsumer.java:330)
> >> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
> >> >> >>>> sumer.java:196)
> >> >> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
> >> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> >> >> >>>> ssorImpl.java:62)
> >> >> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> >> >> >>>> thodAccessorImpl.java:43)
> >> >> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
> >> >> >>>> at com.intellij.rt.execution.application.AppMain.main(
> >> >> AppMain.java:147)
> >> >> >>>> Caused by: javax.jms.JMSException: No route to the destination
> >> >> >>>> node
> >> >> >>>> [condition = qd:no-route-to-dest]
> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >> >> >>>> tion(AmqpSupport.java:150)
> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >> >> >>>> tion(AmqpSupport.java:105)
> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
> >> >> >>>> elyClosed(AmqpAbstractResource.java:147)
> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
> >> >> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
> >> >> >>>> s(AmqpProvider.java:795)
> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
> >> >> >>>> mqpProvider.java:90)
> >> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
> >> >> >>>> ovider.java:699)
> >> >> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
> >> >> >>>> Executors.java:511)
> >> >> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >> >> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> >> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >> >> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
> >> >> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> >> >> >>>> Executor.java:1142)
> >> >> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> >> >> >>>> lExecutor.java:617)
> >> >> >>>> at java.lang.Thread.run(Thread.java:745)
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> -------------------
> >> >> >>>> Dispatch Router (PN_TRACE_FRM=1)
> >> >> >>>> -------------------
> >> >> >>>>
> >> >> >>>> [832220]: <- SASL
> >> >> >>>> [832220]: -> SASL
> >> >> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
> >> >> >>>> MBOL[:ANONYMOUS]]
> >> >> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
> >> >> >>>> initial-response=b"", hostname="host-name"]
> >> >> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
> >> >> >>>> [832220]: <- AMQP
> >> >> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
> >> >> a334-44c3-954a-2dd910161411:1",
> >> >> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
> >> >> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
> >> >> >>>> L[:"sole-connection-for-container"],
> >> properties={:product="QpidJMS",
> >> >> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
> >> >> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
> >> >> >>>> [832220]: -> AMQP
> >> >> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
> >> >> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> >> >> >>>> offered-capabilities=:"ANONYMOUS-RELAY",
> >> properties={:product="qpid-
> >> >> dispatch-router",
> >> >> >>>> :version="0.7.0"}]
> >> >> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1,
> >> >> >>>> incoming-window=2047,
> >> >> >>>> outgoing-window=2147483647, handle-max=65535]
> >> >> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
> >> >> >>>> incoming-window=61, outgoing-window=2147483647]
> >> >> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1,
> >> >> >>>> incoming-window=2047,
> >> >> >>>> outgoing-window=2147483647, handle-max=65535]
> >> >> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
> >> >> >>>> incoming-window=61, outgoing-window=2147483647]
> >> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
> >> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
> >> source=@source(40)
> >> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
> >> durable=0,
> >> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list",
> >> :"amqp:rejected:list"]],
> >> >> >>>> target=@target(41) [address="$management", durable=0,
> >> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >> >> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
> >> >> >>>> initial-delivery-count=0]
> >> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
> >> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >> >> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0,
> >> >> >>>> source=@source(40)
> >> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
> >> durable=0,
> >> >> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:acc
> >> epted:list",
> >> >> >>>> :"amqp:rejected:list"]], target=@target(41)
> >> >> >>>> [address="$management",
> >> >> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
> >> >> queue]],
> >> >> >>>> initial-delivery-count=0, max-message-size=0]
> >> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> >> delivery-count=0,
> >> >> >>>> link-credit=250, drain=false]
> >> >> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
> >> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> >> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
> >> source=@source(40)
> >> >> [],
> >> >> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
> >> >> timeout=0,
> >> >> >>>> dynamic=true, dynamic-node-properties={:"lif
> >> >> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
> >> >> temporary-queue"]],
> >> >> >>>> incomplete-unsettled=false, initial-delivery-count=0]
> >> >> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
> >> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> >> >> role=true,
> >> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> >> [durable=0,
> >> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> >> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
> >> >> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43)
> >> []},
> >> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
> >> >> initial-delivery-count=0,
> >> >> >>>> max-message-size=0]
> >> >> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> >> delivery-count=0,
> >> >> >>>> link-credit=250, drain=false]
> >> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
> >> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
> >> role=true,
> >> >> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> >> [durable=0,
> >> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> >> >> >>>> default-outcome=@modified(39) [delivery-failed=true],
> >> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> >> >> >>>> :"amqp:released:list", :"amqp:modified:list"],
> >> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41)
> >> []]
> >> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
> >> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
> >> role=false,
> >> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> >> [durable=0,
> >> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> >> timeout=0,
> >> >> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
> >> >> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
> >> >> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
> >> >> >>>> destination node"]]
> >> >> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
> >> >> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
> >> >> delivery-tag=b"0",
> >> >> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
> >> >> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
> >> >> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
> >> >> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
> >> >> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
> >> >> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
> >> >> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
> >> >> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
> >> >> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
> >> >> >>>> x04addr\xa1\x0dbrokerMachine"
> >> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
> >> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> >> delivery-count=1,
> >> >> >>>> link-credit=250, drain=false]
> >> >> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
> >> >> >>>> settled=true, state=@accepted(36) []]
> >> >> >>>> [832220]:0 <- @close(24) []
> >> >> >>>> [832220]: <- EOS
> >> >> >>>> [832220]:0 -> @close(24) []
> >> >> >>>> [832220]: -> EOS
> >> >> >>>> Closed x.x.x.x:8961
> >> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >> >> >>>>
> >> >> >>>> ------------------
> >> >> >>>> JMS Client (PN_TRACE_FRM=1)
> >> >> >>>> ------------------
> >> >> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
> >> >> 4a22-9b22-69d27a017a83:1',
> >> >> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
> >> >> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
> >> >> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
> >> >> connection-for-container],
> >> >> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM:
> >> 1.8.0_111,
> >> >> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
> >> >> >>>> [1244186219:0] <- Open{ containerId='router.10200',
> >> hostname='null',
> >> >> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
> >> >> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
> >> >> ANONYMOUS-RELAY],
> >> >> >>>> desiredCapabilities=null, properties={product=qpid-dispa
> >> tch-router,
> >> >> >>>> version=0.7.0}}
> >> >> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> >> properties=null}
> >> >> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> >> >> >>>> incomingWindow=61, outgoingWindow=2147483647,
> >> >> >>>> handleMax=4294967295,
> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> >> properties=null}
> >> >> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> >> properties=null}
> >> >> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
> >> >> >>>> incomingWindow=61, outgoingWindow=2147483647,
> >> >> >>>> handleMax=4294967295,
> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> >> properties=null}
> >> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
> >> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
> >> handle=0,
> >> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> >> >> 3293ffc57168:1:1:1',
> >> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> >> >> amqp:rejected:list],
> >> >> >>>> capabilities=null}, target=Target{address='$management',
> >> >> durable=NONE,
> >> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> >> >> maxMessageSize=null,
> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> >> properties=null}
> >> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
> >> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
> >> handle=0,
> >> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> >> >> 3293ffc57168:1:1:1',
> >> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> >> >> amqp:rejected:list],
> >> >> >>>> capabilities=null}, target=Target{address='$management',
> >> >> durable=NONE,
> >> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> >> maxMessageSize=0,
> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> >> properties=null}
> >> >> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
> >> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> >> deliveryCount=0,
> >> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> >> properties=null}
> >> >> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
> >> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >> >>>> source=Source{address='null', durable=NONE,
> >> expiryPolicy=SESSION_END,
> >> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> >> outcomes=null,
> >> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> >> >> maxMessageSize=null,
> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> >> properties=null}
> >> >> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
> >> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >> >>>> source=Source{address='null', durable=NONE,
> >> expiryPolicy=SESSION_END,
> >> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> >> outcomes=null,
> >> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> >> maxMessageSize=0,
> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> >> properties=null}
> >> >> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
> >> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> >> deliveryCount=0,
> >> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> >> properties=null}
> >> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
> >> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >> >> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >> >>>> source=Source{address='null', durable=NONE,
> >> expiryPolicy=LINK_DETACH,
> >> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
> >> >> deliveryFailed=true,
> >> >> >>>> undeliverableHere=null, messageAnnotations=null},
> >> >> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list,
> >> amqp:released:list,
> >> >> >>>> amqp:modified:list], capabilities=[temporary-queue]},
> >> >> >>>> target=Target{address='null', durable=NONE,
> >> expiryPolicy=SESSION_END,
> >> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >> capabilities=null},
> >> >> >>>> unsettled=null, incompleteUnsettled=false,
> >> initialDeliveryCount=null,
> >> >> >>>> maxMessageSize=null, offeredCapabilities=null,
> >> >> desiredCapabilities=null,
> >> >> >>>> properties=null}
> >> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
> >> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >> >> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >> >>>> source=Source{address='null', durable=NONE,
> >> expiryPolicy=SESSION_END,
> >> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> >> outcomes=null,
> >> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> >> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> >> maxMessageSize=0,
> >> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> >> properties=null}
> >> >> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
> >> >> >>>> error=Error{condition=qd:no-route-to-dest, description='No route
> >> to
> >> >> the
> >> >> >>>> destination node', info=null}}
> >> >> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
> >> >> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
> >> >> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
> >> >> state=null,
> >> >> >>>> resume=false, aborted=false, batchable=false} (312)
> >> >> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
> >> >> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
> >> >> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$man
> >> agement@
> >> >> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
> >> >> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
> >> >> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
> >> >> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
> >> >> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
> >> >> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
> >> >> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
> >> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> >> deliveryCount=1,
> >> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> >> properties=null}
> >> >> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
> >> >> >>>> settled=true, state=Accepted{}, batchable=false}
> >> >> >>>> [1244186219:0] -> Close{error=null}
> >> >> >>>> [1244186219:0] <- Close{error=null}
> >> >> >>>>
> >> >> >>>> Regards,
> >> >> >>>>
> >> >> >>>> Adel
> >> >> >>>>
> >> >> >>>> ________________________________
> >> >> >>>> From: Robbie Gemmell <ro...@gmail.com>
> >> >> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
> >> >> >>>> To: users@qpid.apache.org
> >> >> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >> >> >>>>
> >> >> >>>> That looks fine at first glance. Its possible there is an issue in
> >> >> >>>> there needing looked it. I am travelling this week so may not get
> >> to
> >> >> >>>> look until afterwards, but will try to give things a look at. If
> >> you
> >> >> >>>> could give more detail on the exception and maybe a protocol trace
> >> >> >>>> that might be useful.
> >> >> >>>>
> >> >> >>>> Robbie
> >> >> >>>>
> >> >> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com>
> >> wrote:
> >> >> >>>>
> >> >> >>>>> Hello Robbie,
> >> >> >>>>>
> >> >> >>>>> Thanks for you for your answer.
> >> >> >>>>> I will try the solutions you proposed.
> >> >> >>>>>
> >> >> >>>>> I need just need one clarification. Concerning the Jms, I already
> >> >> tried
> >> >> >>>>> to
> >> >> >>>>> use a temporary queue but it didn't work. May be i am using it
> >> wrong.
> >> >> >>>>> Here
> >> >> >>>>> is what i did:
> >> >> >>>>>
> >> >> >>>>> ...
> >> >> >>>>> Session session = connection.createSession(false,
> >> >> >>>>> Session.AUTO_ACKNOWLEDGE);
> >> >> >>>>> Queue queue = session.createQueue("$management");
> >> >> >>>>> MessageProducer producer = session.createProducer(queue);
> >> >> >>>>>
> >> >> >>>>> Queue tempDest = session.createTemporaryQueue();
> >> >> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDes
> >> t);
> >> >> >>>>> connection.start();
> >> >> >>>>>
> >> >> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
> >> >> >>>>> objectMessage.setJMSReplyTo(tempDest);
> >> >> >>>>> //fill the rest of the parameters ...
> >> >> >>>>> producer.send(objectMessage);
> >> >> >>>>> ObjectMessage replyMessage = (ObjectMessage)
> >> >> >>>>> responseConsumer.receive(1000);
> >> >> >>>>> ...
> >> >> >>>>>
> >> >> >>>>> I was getting an exception on the .receive() from the dispatch
> >> router
> >> >> >>>>> saying that the reply-to address is bad...
> >> >> >>>>> Should i create the temporary queue and the consumer from a
> >> different
> >> >> >>>>> session then the producer?
> >> >> >>>>>
> >> >> >>>>> Best regards,
> >> >> >>>>> Rabih
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
> >> >> >>>>> robbie.gemmell@gmail.com>
> >> >> >>>>> wrote:
> >> >> >>>>>
> >> >> >>>>> The session.createTemporaryQueue(); method is how JMS creates
> >> >> >>>>>> temporary destinations for use in reply-to scenarios. The
> >> dispatch
> >> >> >>>>>> tools will be doing essentially the same thing under the covers
> >> for
> >> >> >>>>>> theirs.
> >> >> >>>>>>
> >> >> >>>>>> Both work by creating a 'dynamic' link attachment, with the
> >> server
> >> >> >>>>>> returning an address for the dynamic attach to the client. One
> >> key
> >> >> >>>>>> difference is with JMS you create the temporary destination (for
> >> >> which
> >> >> >>>>>> the client uses a dynamic sender link to create), then
> >> >> >>>>>> separately
> >> >> >>>>>> create a receiver using it (and in turn the address associated
> >> with
> >> >> >>>>>> it), whereas non-JMS client/tools will typically just create a
> >> >> single
> >> >> >>>>>> dynamic receiver link and use its address for the reply-to.
> >> >> >>>>>>
> >> >> >>>>>> For proton-j, there aren't any examples for this, but you you
> >> >> >>>>>> essentially would change the link opening to not specify an
> >> address,
> >> >> >>>>>> and instead set the source(for a receiver) or target (for a
> >> sender)
> >> >> to
> >> >> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
> >> >> remoteTarget
> >> >> >>>>>> once the link had been reemotely attached, and get its
> >> >> >>>>>> (server-generated) address, then use this as your reply-to.
> >> >> >>>>>>
> >> >> >>>>>> Robbie
> >> >> >>>>>>
> >> >> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
> >> >> wrote:
> >> >> >>>>>>
> >> >> >>>>>>> Hello,
> >> >> >>>>>>>
> >> >> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like
> >> you
> >> >> >>>>>>> suggested, it worked.
> >> >> >>>>>>> But I cheated a little to make it work because I did not find a
> >> >> way in
> >> >> >>>>>>>
> >> >> >>>>>> JMS
> >> >> >>>>>>
> >> >> >>>>>>> to create a local queue. So I created a queue on the
> >> qpid-dispatch
> >> >> and
> >> >> >>>>>>>
> >> >> >>>>>> read
> >> >> >>>>>>
> >> >> >>>>>>> the result from it. You can check the attached code.
> >> >> >>>>>>>
> >> >> >>>>>>> Is there any way using qpid-jms to create a local queue on the
> >> >> client
> >> >> >>>>>>>
> >> >> >>>>>> side
> >> >> >>>>>>
> >> >> >>>>>>> to serve as a reply to address?
> >> >> >>>>>>>
> >> >> >>>>>>> For the proton-j test, I have the same question as above. I saw
> >> >> that
> >> >> >>>>>>> it
> >> >> >>>>>>>
> >> >> >>>>>> can
> >> >> >>>>>>
> >> >> >>>>>>> be done with the C++ API. Are there any examples for proton-j
> >> >> >>>>>>> or
> >> >> >>>>>>>
> >> >> >>>>>> something
> >> >> >>>>>>
> >> >> >>>>>>> that can help me?
> >> >> >>>>>>>
> >> >> >>>>>>> I saw may be in proton we don't need a local queue, may be we
> >> can
> >> >> get
> >> >> >>>>>>> the
> >> >> >>>>>>> address of the consumer directly and pass it in reply-to field.
> >> Is
> >> >> it
> >> >> >>>>>>> correct?
> >> >> >>>>>>>
> >> >> >>>>>>> Thanks,
> >> >> >>>>>>> Rabih
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
> >> >> >>>>>>> rob.j.godfrey@gmail.com>
> >> >> >>>>>>> wrote:
> >> >> >>>>>>>
> >> >> >>>>>>>>
> >> >> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gmurthy@redhat.com
> >> >
> >> >> >>>>>>>> wrote:
> >> >> >>>>>>>>
> >> >> >>>>>>>>
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> ----- Original Message -----
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
> >> >> >>>>>>>>>> To: users@qpid.apache.org
> >> >> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
> >> >> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from
> >> >> >>>>>>>>>> Qpid
> >> >> Jms
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
> >> >> wrote:
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like
> >> >> >>>>>>>>>>>> you
> >> >> told
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>> me
> >> >> >>>>>>
> >> >> >>>>>>> Robbie and it worked.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> But like the proton-j case, the connector is not being
> >> >> created on
> >> >> >>>>>>>>>>>> the
> >> >> >>>>>>>>>>>> Qpid-dispatch side.
> >> >> >>>>>>>>>>>> I attached the amqp communication into this mail.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> The last frame in that file is incomplete (the previous
> >> error
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>> regarding the
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
> >> >> frame
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>> is
> >> >> >>>>>>
> >> >> >>>>>>> likely
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>> the response which would indicate the success or otherwise
> >> >> >>>>>>>>>> of
> >> >> the
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>> frame. Is
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>> there anything logged by the router?
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
> >> >> simpler
> >> >> >>>>>>>>>>> for
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>> this
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>> sort of thing in my view.
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more
> >> helpful.
> >> >> >>>>>>>>>> You
> >> >> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
> >> >> since
> >> >> >>>>>>>>>> it
> >> >> >>>>>>>>>> uses proton-j.
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> One key difference from the qdmanage case is you are not
> >> >> setting a
> >> >> >>>>>>>>>> reply-to value or correlation-id to use along with it. I
> >> don't
> >> >> know
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>> if
> >> >> >>>>>>
> >> >> >>>>>>> the router cares about not being able to send a response or not
> >> >> >>>>>>>>>> though, but it might.
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> You could add the following to your dispatch router conf file
> >> >> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable
> >> trace
> >> >> >>>>>>>>>
> >> >> >>>>>>>> logging)
> >> >> >>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>>> log {
> >> >> >>>>>>>>> module: DEFAULT
> >> >> >>>>>>>>> enable: trace+
> >> >> >>>>>>>>> output: /path/to/log/qdrouterd.log
> >> >> >>>>>>>>> }
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> When you run your management request, you will see proton
> >> frame
> >> >> >>>>>>>>> trace
> >> >> >>>>>>>>> and
> >> >> >>>>>>>>> you will see additional logging out of the dispatch Python
> >> agent
> >> >> -
> >> >> >>>>>>>>> something like the following -
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
> >> >> >>>>>>>>> Message(address=None,
> >> >> >>>>>>>>> properties={'operation': 'CREATE', 'type':
> >> >> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
> >> >> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
> >> >> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
> >> >> >>>>>>>>>
> >> >> >>>>>>>> 'rabih.connector'},
> >> >> >>>>>>
> >> >> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
> >> >> >>>>>>>>> correlation_id=1L)
> >> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured
> >> >> >>>>>>>>> Connector:
> >> >> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
> >> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
> >> >> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True,
> >> cost=1,
> >> >> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
> >> >> 5673:rabih.connector,
> >> >> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
> >> >> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
> >> >> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.
> >> connector,
> >> >> >>>>>>>>> verifyHostName=True)
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> The Python management agent will not process your request if
> >> >> there
> >> >> >>>>>>>>> is
> >> >> >>>>>>>>>
> >> >> >>>>>>>> no
> >> >> >>>>>>
> >> >> >>>>>>> reply_to as seen here -
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
> >> >> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
> >> >> because
> >> >> >>>>>>>> there
> >> >> >>>>>>>> is
> >> >> >>>>>>>> a reply-to doesn't mean that the sender will be around to
> >> actually
> >> >> >>>>>>>> hear
> >> >> >>>>>>>> the
> >> >> >>>>>>>> reply, so it seems a bit arbitrary to say that because we
> >> *know*
> >> >> the
> >> >> >>>>>>>> sender
> >> >> >>>>>>>> won't learn of the outcome that we won't do anything... The
> >> spec
> >> >> >>>>>>>> draft
> >> >> >>>>>>>> doesn't currently say anything about this (obviously it should
> >> >> do),
> >> >> >>>>>>>> but
> >> >> >>>>>>>>
> >> >> >>>>>>> my
> >> >> >>>>>>
> >> >> >>>>>>> expectation would certainly be that a request would be
> >> >> >>>>>>> processed
> >> >> even
> >> >> >>>>>>>> if
> >> >> >>>>>>>> the replyTo address was not present (or ended up not routing
> >> >> >>>>>>>> anywhere).
> >> >> >>>>>>>> This is also how the Qpid Broker for Java implements this
> >> >> >>>>>>>> case.
> >> >> >>>>>>>>
> >> >> >>>>>>>> -- Rob
> >> >> >>>>>>>>
> >> >> >>>>>>>>
> >> >> >>>>>>>> Thanks.
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>> Robbie
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> ------------------------------------------------------------
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>> ---------
> >> >> >>>>>>
> >> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>> ------------------------------------------------------------
> >> >> >>>>>>>>> ---------
> >> >> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>> ------------------------------------------------------------
> >> >> ---------
> >> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >> >>>>>>>
> >> >> >>>>>>
> >> >> >>>>>> ------------------------------------------------------------
> >> >> ---------
> >> >> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>> ------------------------------------------------------------
> >> ---------
> >> >> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> >>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >> >>>>
> >> >> >>>>
> >> >> >>> ------------------------------------------------------------
> >> ---------
> >> >> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> >>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >> >>>
> >> >> >>>
> >> >> >> ------------------------------------------------------------
> >> ---------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> >> For additional commands, e-mail: users-help@qpid.apache.org
> >> >> >>
> >> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>
> >> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Adel Boutros <Ad...@live.com>.
Hello,
One more issue: I am trying to replicate a "qdstat -a" to get the statistics of the addresses.
It seems the 'name' and 'identity' fields returned are always prefixed by some weird combinations "L" or "M0" or "L$", etc. Is this expected?
Output
--------------
attributeNames: [name, identity, type, key, distribution, inProcess, subscriberCount, remoteCount, containerCount, remoteHostRouters, deliveriesIngress, deliveriesEgress, deliveriesTransit, deliveriesToContainer, deliveriesFromContainer, transitOutstanding, trackedDeliveries]
results: [[Lqdhello, Lqdhello, org.apache.qpid.dispatch.router.address, Lqdhello, flood, 1, 0, 0, 0, [], 0, 0, 0, 0, 1379, null, 0], [Lqdrouter, Lqdrouter, org.apache.qpid.dispatch.router.address, Lqdrouter, flood, 1, 0, 0, 0, [], 0, 0, 0, 0, 0, null, 0], [Lqdrouter.ma, Lqdrouter.ma, org.apache.qpid.dispatch.router.address, Lqdrouter.ma, multicast, 1, 0, 0, 0, [], 0, 0, 0, 0, 0, null, 0], [Tqdrouter, Tqdrouter, org.apache.qpid.dispatch.router.address, Tqdrouter, flood, 1, 0, 0, 0, [], 0, 0, 0, 0, 46, null, 0], [Tqdrouter.ma, Tqdrouter.ma, org.apache.qpid.dispatch.router.address, Tqdrouter.ma, multicast, 1, 0, 0, 0, [], 0, 0, 0, 0, 2, null, 0], [M0$management, M0$management, org.apache.qpid.dispatch.router.address, M0$management, closest, 1, 0, 0, 0, [], 7, 0, 0, 7, 0, null, 0], [L$management, L$management, org.apache.qpid.dispatch.router.address, L$management, closest, 1, 0, 0, 0, [], 0, 0, 0, 0, 0, null, 0], [L$_management_internal, L$_management_internal, org.apache.qpid.dispatch.router.address, L$_management_internal, closest, 1, 0, 0, 0, [], 0, 0, 0, 0, 0, null, 0], [L$displayname, L$displayname, org.apache.qpid.dispatch.router.address, L$displayname, closest, 1, 0, 0, 0, [], 0, 0, 0, 0, 0, null, 0], [M0$management_reply_queue, M0$management_reply_queue, org.apache.qpid.dispatch.router.address, M0$management_reply_queue, balanced, 0, 1, 0, 0, [], 0, 0, 0, 0, 0, null, 0]]
Code
---------------
ConnectionFactory connectionFactory = new JmsConnectionFactory("amqp://green-lx-slave1:10501");
Connection managementConnection = connectionFactory.createConnection();
Session managementSession = managementConnection.createSession(false, Session.AUTO_ACKNOWLEDGE);
Queue managementQueue = managementSession.createQueue("$management");
MessageProducer managementProducer = managementSession.createProducer(managementQueue);
Queue replyToQueue = managementSession.createQueue("$management_reply_queue");
MessageConsumer managementConsumer = managementSession.createConsumer(replyToQueue);
managementConnection.start();
// An object message should be used because the Map and List content must be encoded with AMQP encoding.
ObjectMessage objectMessage = managementSession.createObjectMessage();
// Setting management message header properties
// JMS_AMQP_TYPED_ENCODING is a temporary solution that is used by qpid-jms to encode the message content with AMQP encoding before sending it.
objectMessage.setBooleanProperty("JMS_AMQP_TYPED_ENCODING", true);
objectMessage.setStringProperty("operation", "QUERY");
objectMessage.setStringProperty("type", "org.apache.qpid.dispatch.router.address");
objectMessage.setStringProperty("name", "self");
objectMessage.setJMSReplyTo(replyToQueue);
managementProducer.send(objectMessage);
ObjectMessage replyMessage = (ObjectMessage) managementConsumer.receive();
Map<String, Object> resultObject = (Map<String, Object>) replyMessage.getObject();
for (Map.Entry<String, Object> entry : resultObject.entrySet()) {
System.out.println(entry.getKey() + ": " + entry.getValue());
}
managementConnection.close();
Regards,
Adel
________________________________
From: Adel Boutros <Ad...@live.com>
Sent: Wednesday, February 22, 2017 12:33:32 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Hello guys,
My basic JMS API is almost ready. I will share it with you soon to have your feedback.
However, I tried one last thing by getting a random queue name and using it as management reply queue to allow multiple configuration sessions simultaneously but it didn't work.
//This doesn't work and crashes the dispatch router
TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
replyToQueue = managementSession.createQueue(temporaryQueue.getQueueName());
managementConsumer = managementSession.createConsumer(replyToQueue);
//This is the only thing working
replyToQueue = managementSession.createQueue("HARD_CODED_REPLY_QUEUE");
managementConsumer = managementSession.createConsumer(replyToQueue);
Can I have your input on the above?
Regards,
Adel
________________________________
From: Rob Godfrey <ro...@gmail.com>
Sent: Wednesday, February 15, 2017 4:46:59 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
On 15 February 2017 at 16:07, Robbie Gemmell <ro...@gmail.com>
wrote:
> On 15 February 2017 at 14:15, Adel Boutros <Ad...@live.com> wrote:
> > Hello guys,
> >
> >
> > Based on the discussion, we are currently writing a Java API based on
> JMS to configure the dispatch router. I have so far managed to do the
> following:
> >
> > * Create, Read, Delete addresses
> >
> > * Create, Read, Delete connectors
> >
> >
> > Config:
> >
> > Dispatch Router 0.7.0
> >
> > JMS 0.11.1
> >
> >
> > And I have noticed some problems and differences:
> >
> >
> > 1) It seems some calls return ObjectMessage and some TextMessage (This
> is on the side of the consumer in the replyTo)
> >
> > For example, creating twice the same queue will fail but the second call
> will return a JmsTextMessage with an empty body and status code 400
> >
>
> The client treats messages with an amqp-value sectioning containing
> null/nothing as a TextMessage with null value if they arent annotated
> to say otherwise, I'd guess thats where that comes from.
>
> >
> > 2) Returned statusCode differs between Connector and Address
> >
> > Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
> >
> >
> > * Connector operations return java.lang.Long
> > * Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
> >
>
> The router is presumably sending different values back for the
> different operations here, a long and a uint. The router should
> perhaps be consistent, and the client should perhaps not be returning
> the uint object either way.
>
> The last draft of the management spec seems to say the status code
> should be 'integer', im not clear if it means int (not uint)
> specifically, or just any integral type value.
>
>
The specification should definitely say which type should - so we'll fix
that in the next draft. I'd suggest we should int (in AMQP terms) leading
to a java.lang.Integer type in the property you see through Java.
-- Rob
> >
> > 3) Create connector twice makes dispatch router crash. I don't have the
> issue when creating addresses.
> > On the second create call, JMS client receives a normal reply
> containing a statusCode of an exception. After I close the connection to
> the dispatch router via JMS (connection.close), I have the below crash
> >
> > (gdb) where
> > #0 0x00007f27194448a5 in raise () from /lib64/libc.so.6
> > #1 0x00007f2719446085 in abort () from /lib64/libc.so.6
> > #2 0x00007f27194827b7 in __libc_message () from /lib64/libc.so.6
> > #3 0x00007f27194880e6 in malloc_printerr () from /lib64/libc.so.6
> > #4 0x00007f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf
> expression opcode 0xf3
> > ) at /qpid-dispatch-0.7.0/src/hash.c:320
> > #5 0x00007f271a42247d in qdr_route_check_id_for_deletion_CT
> (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
> > ) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
> > #6 0x00007f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30,
> action=Unhandled dwarf expression opcode 0xf3
> > ) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
> > #7 0x00007f271a423f30 in router_core_thread (arg=0x13d2d30) at
> /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
> > #8 0x00007f2719f8c851 in start_thread () from /lib64/libpthread.so.0
> > #9 0x00007f27194fa90d in clone () from /lib64/libc.so.6
> >
> >
> > Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE:
> org.apache.qpid.dispatch.connector: Duplicate value 'connector/
> 127.0.0.1:5915:dispatch_management_connector_test' for unique attribute
> 'identity'
> > *** glibc detected *** /Dispatch/sbin/qdrouterd: double free or
> corruption (fasttop): 0x00007f2708033f10 ***
> > ======= Backtrace: =========
> > /lib64/libc.so.6(+0x760e6)[0x7f27194880e6]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> .so(qd_hash_remove_by_handle+0x29)[0x7f271a40f109]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> .so(+0x3547d)[0x7f271a42247d]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> .so(+0x318d3)[0x7f271a41e8d3]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> .so(router_core_thread+0x230)[0x7f271a423f30]
> > /lib64/libpthread.so.0(+0x7851)[0x7f2719f8c851]
> > /lib64/libc.so.6(clone+0x6d)[0x7f27194fa90d]
> > ======= Memory map: ========
> > 00400000-00403000 r-xp 00000000 fd:01 7735642
> /Dispatch/sbin/qdrouterd
> > 00603000-00604000 rw-p 00003000 fd:01 7735642
> /Dispatch/sbin/qdrouterd
> > 01113000-01458000 rw-p 00000000 00:00 0
> [heap]
> > 7f26f8000000-7f26f805c000 rw-p 00000000 00:00 0
> > 7f26f805c000-7f26fc000000 ---p 00000000 00:00 0
> > 7f26fc000000-7f26fc043000 rw-p 00000000 00:00 0
> > 7f26fc043000-7f2700000000 ---p 00000000 00:00 0
> > 7f2700000000-7f2700085000 rw-p 00000000 00:00 0
> > 7f2700085000-7f2704000000 ---p 00000000 00:00 0
> > 7f27073e9000-7f27073ff000 r-xp 00000000 fd:00 524293
> /lib64/libgcc_s-4.4.7-20120601.so.1
> > 7f27073ff000-7f27075fe000 ---p 00016000 fd:00 524293
> /lib64/libgcc_s-4.4.7-20120601.so.1
> > 7f27075fe000-7f27075ff000 rw-p 00015000 fd:00 524293
> /lib64/libgcc_s-4.4.7-20120601.so.1
> > 7f27075ff000-7f2707600000 ---p 00000000 00:00 0
> > 7f2707600000-7f2708000000 rw-p 00000000 00:00 0
> > 7f2708000000-7f270805a000 rw-p 00000000 00:00 0
> > 7f270805a000-7f270c000000 ---p 00000000 00:00 0
> > 7f270c04a000-7f270c04f000 r-xp 00000000 fd:00 524322
> /lib64/libnss_dns-2.12.so
> > 7f270c04f000-7f270c24e000 ---p 00005000 fd:00 524322
> /lib64/libnss_dns-2.12.so
> > 7f270c24e000-7f270c24f000 r--p 00004000 fd:00 524322
> /lib64/libnss_dns-2.12.so
> > 7f270c24f000-7f270c250000 rw-p 00005000 fd:00 524322
> /lib64/libnss_dns-2.12.so
> > 7f270c250000-7f270c251000 ---p 00000000 00:00 0
> > 7f270c251000-7f270cc51000 rw-p 00000000 00:00 0
> > 7f270cc51000-7f270cc52000 ---p 00000000 00:00 0
> > 7f270cc52000-7f270d652000 rw-p 00000000 00:00 0
> > 7f270d652000-7f270d65e000 r-xp 00000000 fd:00 524324
> /lib64/libnss_files-2.12.so
> > 7f270d65e000-7f270d85e000 ---p 0000c000 fd:00 524324
> /lib64/libnss_files-2.12.so
> > 7f270d85e000-7f270d85f000 r--p 0000c000 fd:00 524324
> /lib64/libnss_files-2.12.so
> > 7f270d85f000-7f270d860000 rw-p 0000d000 fd:00 524324
> /lib64/libnss_files-2.12.so
> > 7f270d86a000-7f270d86b000 ---p 00000000 00:00 0
> > 7f270d86b000-7f270e3ac000 rw-p 00000000 00:00 0
> > 7f270e3ac000-7f270e3b1000 r-xp 00000000 00:16 4090944
> /python278/lib/python2.7/lib-dynload/select.so
> > 7f270e3b1000-7f270e5b0000 ---p 00005000 00:16 4090944
> /python278/lib/python2.7/lib-dynload/select.so
> > 7f270e5b0000-7f270e5b2000 rw-p 00004000 00:16 4090944
> /python278/lib/python2.7/lib-dynload/select.so
> > 7f270e5b2000-7f270e5b6000 r-xp 00000000 00:16 5568743
> /python278/lib/python2.7/lib-dynload/_lsprof.so
> > 7f270e5b6000-7f270e7b5000 ---p 00004000 00:16 5568743
> /python278/lib/python2.7/lib-dynload/_lsprof.so
> > 7f270e7b5000-7f270e7b6000 rw-p 00003000 00:16 5568743
> /python278/lib/python2.7/lib-dynload/_lsprof.so
> > 7f270e7b6000-7f270e8b7000 rw-p 00000000 00:00 0
> > 7f270e8b7000-7f270e8bc000 r-xp 00000000 00:16 6394000
> /python278/lib/python2.7/lib-dynload/strop.so
> > 7f270e8bc000-7f270eabb000 ---p 00005000 00:16 6394000
> /python278/lib/python2.7/lib-dynload/strop.so
> > 7f270eabb000-7f270eabd000 rw-p 00004000 00:16 6394000
> /python278/lib/python2.7/lib-dynload/strop.so
> > 7f270eabd000-7f270eafd000 rw-p 00000000 00:00 0
> > 7f270eafd000-7f270eb00000 r-xp 00000000 00:16 5568749
> /python278/lib/python2.7/lib-dynload/fcntl.so
> > 7f270eb00000-7f270ecff000 ---p 00003000 00:16 5568749
> /python278/lib/python2.7/lib-dynload/fcntl.so
> > 7f270ecff000-7f270ed01000 rw-p 00002000 00:16 5568749
> /python278/lib/python2.7/lib-dynload/fcntl.so
> > 7f270ed01000-7f270ed04000 r-xp 00000000 00:16 5568739
> /python278/lib/python2.7/lib-dynload/_random.so
> > 7f270ed04000-7f270ef03000 ---p 00003000 00:16 5568739
> /python278/lib/python2.7/lib-dynload/_random.so
> > 7f270ef03000-7f270ef04000 rw-p 00002000 00:16 5568739
> /python278/lib/python2.7/lib-dynload/_random.so
> > 4272 Aborted (core dumped)
> >
> >
> > Regards,
> > Adel
> >
> >
> > ________________________________
> > From: Rob Godfrey <ro...@gmail.com>
> > Sent: Monday, February 6, 2017 7:09 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >
> > On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
> > wrote:
> >
> >> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com>
> wrote:
> >> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
> >> >
> >> >> It seems odd that the client creates a _sender_ to the temporary
> queue
> >> >> that it will never send messages _to_ but will receive messages
> _from_.
> >> >>
> >> >>
> >> > This is because JMS semantics require the temporary node to have a
> >> lifetime
> >> > scoped to the session (not a link), so the JMS client has to create a
> >> > synthetic link which it uses simply to manage the lifetime of the
> dynamic
> >> > node. In order to not cause unintentional assigning of messages to a
> >> link
> >> > that will never actually be used for consumption, a sending link is
> used.
> >> > Note that in general JMS would expect that you should be able to send
> to
> >> a
> >> > temporary queue created in this way (since the point of temporary
> queues
> >> is
> >> > to use as a reply to)
> >> >
> >>
> >> Not really important here, but the lifetime is scoped to the
> >> Connection, not Session (agghhh JMS... :P)
> >>
> >
> > That's what I thought I was typing... obviously my fingers were not
> > cooperating with my brain at that point :-)
> >
> > -- Rob
> >
> >
> >>
> >> >
> >> >> Anyway, when the client creates a receiver with a dynamic source
> (and no
> >> >> dynamic-node-properties), the router will accept the link and assign
> a
> >> >> temporary address as the source. This is only useful in this use
> case
> >> if
> >> >> the broker has a way of knowing that the temporary address is
> reachable
> >> via
> >> >> the router network.
> >> >>
> >> >> There is a way to route dynamic termini to a broker. If an
> >> >> x-opt-qd.address property is included in the dynamic-node-properties,
> >> this
> >> >> address will be used to route the attach to the broker. I've never
> >> tested
> >> >> this with a dynamic target in a sender. It might not work.
> >> >
> >> >
> >> > And this really isn't something you'd be expecting a generic client
> (like
> >> > the JMS client) to know :-)
> >> >
> >> > -- Rob
> >> >
> >> >
> >> >>
> >> >>
> >> >> -Ted
> >> >>
> >> >>
> >> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
> >> >>
> >> >>> I've had a look at this. It would seem that Dispatch doesn't like
> what
> >> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
> >> >>> very nice way, and the client then doesnt notice that things have
> gone
> >> >>> south in a somewhat unexpected way.
> >> >>>
> >> >>> The client opens a sending link with 'dynamic' target in order to
> >> >>> create a dynamic node for use as a TemporaryQueue
> address/destination
> >> >>> object, which specific consumers/producers are then created against
> by
> >> >>> the application. Dispatch doesn't seem to like that but erroneously
> >> >>> attaches the link 'successfully', though doesnt set a target address
> >> >>> as is expected. The client then doesnt notice this happened (its
> >> >>> checking for the link being refused, which it wasn't), allowing the
> >> >>> application to proceed as far as creating consumers/procuers using
> the
> >> >>> TemporaryQueue object, with creation of the e.g Consumer then
> failing
> >> >>> since the attach doesnt contain the needed information and leads to
> >> >>> Dispatch detaching it with the error (though it again doesnt
> actually
> >> >>> indicate its refusing the link during the attach response, as it
> >> >>> probably should have in this case).
> >> >>>
> >> >>> Making the client detect the current failure and having it throw an
> >> >>> aexception from createTemporaryQueue is simple enough.
> >> >>>
> >> >>> Hacking the client to use a dynamic recieving link instead, an
> address
> >> >>> was returned by Dispatch in the attach response as expected,
> however a
> >> >>> consumer on the resulting TemporaryQueue object using this address
> >> >>> still didnt get the message I sent to the same place. If I also gave
> >> >>> some credit on the link backing the TemporaryQeueue object itself
> then
> >> >>> that link gets sent the message by Dispatch, though this of no use
> for
> >> >>> the JMS client.
> >> >>>
> >> >>> Needs some more investigation, and I'll need to discuss with some
> >> >>> folks more familiar with Dispatch.
> >> >>>
> >> >>> Robbie
> >> >>>
> >> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
> >> wrote:
> >> >>>
> >> >>>> Hello Robbie,
> >> >>>>
> >> >>>>
> >> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the
> reply
> >> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS
> Client.
> >> >>>>
> >> >>>>
> >> >>>> PS: As Rabih stated before, we are using the same connection and
> same
> >> >>>> session to create the JMSProducer for the request and the
> >> JMSConsumer for
> >> >>>> the reply.
> >> >>>>
> >> >>>>
> >> >>>> Exception
> >> >>>> -------------------
> >> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed
> due
> >> to
> >> >>>> an unrecoverable error.
> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
> >> >>>> eConsumer.java:330)
> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
> >> >>>> sumer.java:196)
> >> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> >> >>>> ssorImpl.java:62)
> >> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> >> >>>> thodAccessorImpl.java:43)
> >> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
> >> >>>> at com.intellij.rt.execution.application.AppMain.main(
> >> AppMain.java:147)
> >> >>>> Caused by: javax.jms.JMSException: No route to the destination node
> >> >>>> [condition = qd:no-route-to-dest]
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >> >>>> tion(AmqpSupport.java:150)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >> >>>> tion(AmqpSupport.java:105)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
> >> >>>> elyClosed(AmqpAbstractResource.java:147)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
> >> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
> >> >>>> s(AmqpProvider.java:795)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
> >> >>>> mqpProvider.java:90)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
> >> >>>> ovider.java:699)
> >> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
> >> >>>> Executors.java:511)
> >> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
> >> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> >> >>>> Executor.java:1142)
> >> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> >> >>>> lExecutor.java:617)
> >> >>>> at java.lang.Thread.run(Thread.java:745)
> >> >>>>
> >> >>>>
> >> >>>> -------------------
> >> >>>> Dispatch Router (PN_TRACE_FRM=1)
> >> >>>> -------------------
> >> >>>>
> >> >>>> [832220]: <- SASL
> >> >>>> [832220]: -> SASL
> >> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
> >> >>>> MBOL[:ANONYMOUS]]
> >> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
> >> >>>> initial-response=b"", hostname="host-name"]
> >> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
> >> >>>> [832220]: <- AMQP
> >> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
> >> a334-44c3-954a-2dd910161411:1",
> >> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
> >> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
> >> >>>> L[:"sole-connection-for-container"],
> properties={:product="QpidJMS",
> >> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
> >> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
> >> >>>> [832220]: -> AMQP
> >> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
> >> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> >> >>>> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-
> >> dispatch-router",
> >> >>>> :version="0.7.0"}]
> >> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> >> >>>> outgoing-window=2147483647, handle-max=65535]
> >> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
> >> >>>> incoming-window=61, outgoing-window=2147483647]
> >> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> >> >>>> outgoing-window=2147483647, handle-max=65535]
> >> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
> >> >>>> incoming-window=61, outgoing-window=2147483647]
> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
> source=@source(40)
> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
> durable=0,
> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list",
> :"amqp:rejected:list"]],
> >> >>>> target=@target(41) [address="$management", durable=0,
> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
> >> >>>> initial-delivery-count=0]
> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
> durable=0,
> >> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:acc
> epted:list",
> >> >>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
> >> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
> >> queue]],
> >> >>>> initial-delivery-count=0, max-message-size=0]
> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> delivery-count=0,
> >> >>>> link-credit=250, drain=false]
> >> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
> source=@source(40)
> >> [],
> >> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
> >> timeout=0,
> >> >>>> dynamic=true, dynamic-node-properties={:"lif
> >> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
> >> temporary-queue"]],
> >> >>>> incomplete-unsettled=false, initial-delivery-count=0]
> >> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> >> role=true,
> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [durable=0,
> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
> >> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43)
> []},
> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
> >> initial-delivery-count=0,
> >> >>>> max-message-size=0]
> >> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> delivery-count=0,
> >> >>>> link-credit=250, drain=false]
> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
> role=true,
> >> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> [durable=0,
> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> >> >>>> default-outcome=@modified(39) [delivery-failed=true],
> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> >> >>>> :"amqp:released:list", :"amqp:modified:list"],
> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41)
> []]
> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
> role=false,
> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [durable=0,
> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> timeout=0,
> >> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
> >> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
> >> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
> >> >>>> destination node"]]
> >> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
> >> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
> >> delivery-tag=b"0",
> >> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
> >> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
> >> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
> >> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
> >> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
> >> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
> >> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
> >> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
> >> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
> >> >>>> x04addr\xa1\x0dbrokerMachine"
> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> delivery-count=1,
> >> >>>> link-credit=250, drain=false]
> >> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
> >> >>>> settled=true, state=@accepted(36) []]
> >> >>>> [832220]:0 <- @close(24) []
> >> >>>> [832220]: <- EOS
> >> >>>> [832220]:0 -> @close(24) []
> >> >>>> [832220]: -> EOS
> >> >>>> Closed x.x.x.x:8961
> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >> >>>>
> >> >>>> ------------------
> >> >>>> JMS Client (PN_TRACE_FRM=1)
> >> >>>> ------------------
> >> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
> >> 4a22-9b22-69d27a017a83:1',
> >> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
> >> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
> >> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
> >> connection-for-container],
> >> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM:
> 1.8.0_111,
> >> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
> >> >>>> [1244186219:0] <- Open{ containerId='router.10200',
> hostname='null',
> >> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
> >> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
> >> ANONYMOUS-RELAY],
> >> >>>> desiredCapabilities=null, properties={product=qpid-dispa
> tch-router,
> >> >>>> version=0.7.0}}
> >> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
> handle=0,
> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> >> 3293ffc57168:1:1:1',
> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> >> amqp:rejected:list],
> >> >>>> capabilities=null}, target=Target{address='$management',
> >> durable=NONE,
> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> >> maxMessageSize=null,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
> handle=0,
> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> >> 3293ffc57168:1:1:1',
> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> >> amqp:rejected:list],
> >> >>>> capabilities=null}, target=Target{address='$management',
> >> durable=NONE,
> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> deliveryCount=0,
> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> properties=null}
> >> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE,
> expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> outcomes=null,
> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> >> maxMessageSize=null,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE,
> expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> outcomes=null,
> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> deliveryCount=0,
> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> properties=null}
> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE,
> expiryPolicy=LINK_DETACH,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
> >> deliveryFailed=true,
> >> >>>> undeliverableHere=null, messageAnnotations=null},
> >> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list,
> amqp:released:list,
> >> >>>> amqp:modified:list], capabilities=[temporary-queue]},
> >> >>>> target=Target{address='null', durable=NONE,
> expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> capabilities=null},
> >> >>>> unsettled=null, incompleteUnsettled=false,
> initialDeliveryCount=null,
> >> >>>> maxMessageSize=null, offeredCapabilities=null,
> >> desiredCapabilities=null,
> >> >>>> properties=null}
> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE,
> expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> outcomes=null,
> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
> >> >>>> error=Error{condition=qd:no-route-to-dest, description='No route
> to
> >> the
> >> >>>> destination node', info=null}}
> >> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
> >> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
> >> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
> >> state=null,
> >> >>>> resume=false, aborted=false, batchable=false} (312)
> >> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
> >> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
> >> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$man
> agement@
> >> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
> >> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
> >> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
> >> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
> >> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
> >> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
> >> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> deliveryCount=1,
> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> properties=null}
> >> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
> >> >>>> settled=true, state=Accepted{}, batchable=false}
> >> >>>> [1244186219:0] -> Close{error=null}
> >> >>>> [1244186219:0] <- Close{error=null}
> >> >>>>
> >> >>>> Regards,
> >> >>>>
> >> >>>> Adel
> >> >>>>
> >> >>>> ________________________________
> >> >>>> From: Robbie Gemmell <ro...@gmail.com>
> >> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
> >> >>>> To: users@qpid.apache.org
> >> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >> >>>>
> >> >>>> That looks fine at first glance. Its possible there is an issue in
> >> >>>> there needing looked it. I am travelling this week so may not get
> to
> >> >>>> look until afterwards, but will try to give things a look at. If
> you
> >> >>>> could give more detail on the exception and maybe a protocol trace
> >> >>>> that might be useful.
> >> >>>>
> >> >>>> Robbie
> >> >>>>
> >> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com>
> wrote:
> >> >>>>
> >> >>>>> Hello Robbie,
> >> >>>>>
> >> >>>>> Thanks for you for your answer.
> >> >>>>> I will try the solutions you proposed.
> >> >>>>>
> >> >>>>> I need just need one clarification. Concerning the Jms, I already
> >> tried
> >> >>>>> to
> >> >>>>> use a temporary queue but it didn't work. May be i am using it
> wrong.
> >> >>>>> Here
> >> >>>>> is what i did:
> >> >>>>>
> >> >>>>> ...
> >> >>>>> Session session = connection.createSession(false,
> >> >>>>> Session.AUTO_ACKNOWLEDGE);
> >> >>>>> Queue queue = session.createQueue("$management");
> >> >>>>> MessageProducer producer = session.createProducer(queue);
> >> >>>>>
> >> >>>>> Queue tempDest = session.createTemporaryQueue();
> >> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDes
> t);
> >> >>>>> connection.start();
> >> >>>>>
> >> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
> >> >>>>> objectMessage.setJMSReplyTo(tempDest);
> >> >>>>> //fill the rest of the parameters ...
> >> >>>>> producer.send(objectMessage);
> >> >>>>> ObjectMessage replyMessage = (ObjectMessage)
> >> >>>>> responseConsumer.receive(1000);
> >> >>>>> ...
> >> >>>>>
> >> >>>>> I was getting an exception on the .receive() from the dispatch
> router
> >> >>>>> saying that the reply-to address is bad...
> >> >>>>> Should i create the temporary queue and the consumer from a
> different
> >> >>>>> session then the producer?
> >> >>>>>
> >> >>>>> Best regards,
> >> >>>>> Rabih
> >> >>>>>
> >> >>>>>
> >> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
> >> >>>>> robbie.gemmell@gmail.com>
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>> The session.createTemporaryQueue(); method is how JMS creates
> >> >>>>>> temporary destinations for use in reply-to scenarios. The
> dispatch
> >> >>>>>> tools will be doing essentially the same thing under the covers
> for
> >> >>>>>> theirs.
> >> >>>>>>
> >> >>>>>> Both work by creating a 'dynamic' link attachment, with the
> server
> >> >>>>>> returning an address for the dynamic attach to the client. One
> key
> >> >>>>>> difference is with JMS you create the temporary destination (for
> >> which
> >> >>>>>> the client uses a dynamic sender link to create), then separately
> >> >>>>>> create a receiver using it (and in turn the address associated
> with
> >> >>>>>> it), whereas non-JMS client/tools will typically just create a
> >> single
> >> >>>>>> dynamic receiver link and use its address for the reply-to.
> >> >>>>>>
> >> >>>>>> For proton-j, there aren't any examples for this, but you you
> >> >>>>>> essentially would change the link opening to not specify an
> address,
> >> >>>>>> and instead set the source(for a receiver) or target (for a
> sender)
> >> to
> >> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
> >> remoteTarget
> >> >>>>>> once the link had been reemotely attached, and get its
> >> >>>>>> (server-generated) address, then use this as your reply-to.
> >> >>>>>>
> >> >>>>>> Robbie
> >> >>>>>>
> >> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
> >> wrote:
> >> >>>>>>
> >> >>>>>>> Hello,
> >> >>>>>>>
> >> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like
> you
> >> >>>>>>> suggested, it worked.
> >> >>>>>>> But I cheated a little to make it work because I did not find a
> >> way in
> >> >>>>>>>
> >> >>>>>> JMS
> >> >>>>>>
> >> >>>>>>> to create a local queue. So I created a queue on the
> qpid-dispatch
> >> and
> >> >>>>>>>
> >> >>>>>> read
> >> >>>>>>
> >> >>>>>>> the result from it. You can check the attached code.
> >> >>>>>>>
> >> >>>>>>> Is there any way using qpid-jms to create a local queue on the
> >> client
> >> >>>>>>>
> >> >>>>>> side
> >> >>>>>>
> >> >>>>>>> to serve as a reply to address?
> >> >>>>>>>
> >> >>>>>>> For the proton-j test, I have the same question as above. I saw
> >> that
> >> >>>>>>> it
> >> >>>>>>>
> >> >>>>>> can
> >> >>>>>>
> >> >>>>>>> be done with the C++ API. Are there any examples for proton-j or
> >> >>>>>>>
> >> >>>>>> something
> >> >>>>>>
> >> >>>>>>> that can help me?
> >> >>>>>>>
> >> >>>>>>> I saw may be in proton we don't need a local queue, may be we
> can
> >> get
> >> >>>>>>> the
> >> >>>>>>> address of the consumer directly and pass it in reply-to field.
> Is
> >> it
> >> >>>>>>> correct?
> >> >>>>>>>
> >> >>>>>>> Thanks,
> >> >>>>>>> Rabih
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
> >> >>>>>>> rob.j.godfrey@gmail.com>
> >> >>>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gmurthy@redhat.com
> >
> >> >>>>>>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> ----- Original Message -----
> >> >>>>>>>>>
> >> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
> >> >>>>>>>>>> To: users@qpid.apache.org
> >> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
> >> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid
> >> Jms
> >> >>>>>>>>>>
> >> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
> >> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you
> >> told
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>> me
> >> >>>>>>
> >> >>>>>>> Robbie and it worked.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> But like the proton-j case, the connector is not being
> >> created on
> >> >>>>>>>>>>>> the
> >> >>>>>>>>>>>> Qpid-dispatch side.
> >> >>>>>>>>>>>> I attached the amqp communication into this mail.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> The last frame in that file is incomplete (the previous
> error
> >> >>>>>>>>>>>
> >> >>>>>>>>>> regarding the
> >> >>>>>>>>>
> >> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
> >> frame
> >> >>>>>>>>>>>
> >> >>>>>>>>>> is
> >> >>>>>>
> >> >>>>>>> likely
> >> >>>>>>>>>
> >> >>>>>>>>>> the response which would indicate the success or otherwise of
> >> the
> >> >>>>>>>>>>>
> >> >>>>>>>>>> frame. Is
> >> >>>>>>>>>
> >> >>>>>>>>>> there anything logged by the router?
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
> >> simpler
> >> >>>>>>>>>>> for
> >> >>>>>>>>>>>
> >> >>>>>>>>>> this
> >> >>>>>>>>>
> >> >>>>>>>>>> sort of thing in my view.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more
> helpful.
> >> >>>>>>>>>> You
> >> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
> >> since
> >> >>>>>>>>>> it
> >> >>>>>>>>>> uses proton-j.
> >> >>>>>>>>>>
> >> >>>>>>>>>> One key difference from the qdmanage case is you are not
> >> setting a
> >> >>>>>>>>>> reply-to value or correlation-id to use along with it. I
> don't
> >> know
> >> >>>>>>>>>>
> >> >>>>>>>>> if
> >> >>>>>>
> >> >>>>>>> the router cares about not being able to send a response or not
> >> >>>>>>>>>> though, but it might.
> >> >>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> You could add the following to your dispatch router conf file
> >> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable
> trace
> >> >>>>>>>>>
> >> >>>>>>>> logging)
> >> >>>>>>
> >> >>>>>>>
> >> >>>>>>>>> log {
> >> >>>>>>>>> module: DEFAULT
> >> >>>>>>>>> enable: trace+
> >> >>>>>>>>> output: /path/to/log/qdrouterd.log
> >> >>>>>>>>> }
> >> >>>>>>>>>
> >> >>>>>>>>> When you run your management request, you will see proton
> frame
> >> >>>>>>>>> trace
> >> >>>>>>>>> and
> >> >>>>>>>>> you will see additional logging out of the dispatch Python
> agent
> >> -
> >> >>>>>>>>> something like the following -
> >> >>>>>>>>>
> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
> >> >>>>>>>>> Message(address=None,
> >> >>>>>>>>> properties={'operation': 'CREATE', 'type':
> >> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
> >> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
> >> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
> >> >>>>>>>>>
> >> >>>>>>>> 'rabih.connector'},
> >> >>>>>>
> >> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
> >> >>>>>>>>> correlation_id=1L)
> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
> >> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
> >> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True,
> cost=1,
> >> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
> >> 5673:rabih.connector,
> >> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
> >> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
> >> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.
> connector,
> >> >>>>>>>>> verifyHostName=True)
> >> >>>>>>>>>
> >> >>>>>>>>> The Python management agent will not process your request if
> >> there
> >> >>>>>>>>> is
> >> >>>>>>>>>
> >> >>>>>>>> no
> >> >>>>>>
> >> >>>>>>> reply_to as seen here -
> >> >>>>>>>>>
> >> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
> >> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
> >> because
> >> >>>>>>>> there
> >> >>>>>>>> is
> >> >>>>>>>> a reply-to doesn't mean that the sender will be around to
> actually
> >> >>>>>>>> hear
> >> >>>>>>>> the
> >> >>>>>>>> reply, so it seems a bit arbitrary to say that because we
> *know*
> >> the
> >> >>>>>>>> sender
> >> >>>>>>>> won't learn of the outcome that we won't do anything... The
> spec
> >> >>>>>>>> draft
> >> >>>>>>>> doesn't currently say anything about this (obviously it should
> >> do),
> >> >>>>>>>> but
> >> >>>>>>>>
> >> >>>>>>> my
> >> >>>>>>
> >> >>>>>>> expectation would certainly be that a request would be processed
> >> even
> >> >>>>>>>> if
> >> >>>>>>>> the replyTo address was not present (or ended up not routing
> >> >>>>>>>> anywhere).
> >> >>>>>>>> This is also how the Qpid Broker for Java implements this case.
> >> >>>>>>>>
> >> >>>>>>>> -- Rob
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> Thanks.
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>> Robbie
> >> >>>>>>>>>>
> >> >>>>>>>>>> ------------------------------------------------------------
> >> >>>>>>>>>>
> >> >>>>>>>>> ---------
> >> >>>>>>
> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>> ------------------------------------------------------------
> >> >>>>>>>>> ---------
> >> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> ------------------------------------------------------------
> >> ---------
> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> ------------------------------------------------------------
> >> ---------
> >> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>> ------------------------------------------------------------
> ---------
> >> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>
> >> >>>>
> >> >>> ------------------------------------------------------------
> ---------
> >> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>
> >> >>>
> >> >> ------------------------------------------------------------
> ---------
> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Robbie Gemmell <ro...@gmail.com>.
Yes, though the only one I think is actually relevent is probably
Dispatch, since Ted had made some changes to it to support the JMS
clients particular TemporaryQueue behaviour at the end of the previous
week following the discussions around that after your earlier mails.
Mainly I was just trying to reproduce your problem to see where the
issue was, but I wasn't able to.
Robbie
On 24 February 2017 at 17:10, Adel Boutros <Ad...@live.com> wrote:
> Thank you Robbie.
>
>
> So If I understood correctly, in the next release of the components (Dispatch, Proton, JMS), the below is correctly supported because you tested on the Master branches. Right?
>
>
> Regards,
>
> Adel
>
> ________________________________
> From: Robbie Gemmell <ro...@gmail.com>
> Sent: Friday, February 24, 2017 5:43:05 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> I tried this (modified to use a temporary queue) and also modified the
> Qpid JMS HelloWorld example to use a temporary queue, and ran both
> against the router successfully multiple times, using the jms client
> from master, dispatch from master, and proton from master.
>
> The only odd thing was that Dispatch printed out two copies of notices
> about the connection closing without the links being explicitly
> detached, which is what the examples do and not something I would
> consider unusual. I wouldnt really expect to see these notices, but if
> so then only one copy.
>
> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
> due to parent connection end
> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
> due to parent connection end
> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
> due to parent connection end
> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
> due to parent connection end
> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
> due to parent connection end
> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
> due to parent connection end
>
> As an aside, the typical TemporaryQueue usage would be just to use the
> destination object directly, i.e the below, not ask its name and
> create another destination with that name. I tried both ways just to
> check it wasnt related though and they both worked the same.
> TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
> managementConsumer = managementSession.createConsumer(temporaryQueue);
>
>
> On 22 February 2017 at 11:33, Adel Boutros <Ad...@live.com> wrote:
>> Hello guys,
>>
>>
>> My basic JMS API is almost ready. I will share it with you soon to have your feedback.
>>
>>
>> However, I tried one last thing by getting a random queue name and using it as management reply queue to allow multiple configuration sessions simultaneously but it didn't work.
>>
>>
>> //This doesn't work and crashes the dispatch router
>>
>> TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
>> replyToQueue = managementSession.createQueue(temporaryQueue.getQueueName());
>> managementConsumer = managementSession.createConsumer(replyToQueue);
>>
>> //This is the only thing working
>> replyToQueue = managementSession.createQueue("HARD_CODED_REPLY_QUEUE");
>> managementConsumer = managementSession.createConsumer(replyToQueue);
>>
>>
>> Can I have your input on the above?
>>
>> Regards,
>> Adel
>>
>>
>> ________________________________
>> From: Rob Godfrey <ro...@gmail.com>
>> Sent: Wednesday, February 15, 2017 4:46:59 PM
>> To: users@qpid.apache.org
>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>
>> On 15 February 2017 at 16:07, Robbie Gemmell <ro...@gmail.com>
>> wrote:
>>
>>> On 15 February 2017 at 14:15, Adel Boutros <Ad...@live.com> wrote:
>>> > Hello guys,
>>> >
>>> >
>>> > Based on the discussion, we are currently writing a Java API based on
>>> JMS to configure the dispatch router. I have so far managed to do the
>>> following:
>>> >
>>> > * Create, Read, Delete addresses
>>> >
>>> > * Create, Read, Delete connectors
>>> >
>>> >
>>> > Config:
>>> >
>>> > Dispatch Router 0.7.0
>>> >
>>> > JMS 0.11.1
>>> >
>>> >
>>> > And I have noticed some problems and differences:
>>> >
>>> >
>>> > 1) It seems some calls return ObjectMessage and some TextMessage (This
>>> is on the side of the consumer in the replyTo)
>>> >
>>> > For example, creating twice the same queue will fail but the second call
>>> will return a JmsTextMessage with an empty body and status code 400
>>> >
>>>
>>> The client treats messages with an amqp-value sectioning containing
>>> null/nothing as a TextMessage with null value if they arent annotated
>>> to say otherwise, I'd guess thats where that comes from.
>>>
>>> >
>>> > 2) Returned statusCode differs between Connector and Address
>>> >
>>> > Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
>>> >
>>> >
>>> > * Connector operations return java.lang.Long
>>> > * Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
>>> >
>>>
>>> The router is presumably sending different values back for the
>>> different operations here, a long and a uint. The router should
>>> perhaps be consistent, and the client should perhaps not be returning
>>> the uint object either way.
>>>
>>> The last draft of the management spec seems to say the status code
>>> should be 'integer', im not clear if it means int (not uint)
>>> specifically, or just any integral type value.
>>>
>>>
>> The specification should definitely say which type should - so we'll fix
>> that in the next draft. I'd suggest we should int (in AMQP terms) leading
>> to a java.lang.Integer type in the property you see through Java.
>>
>> -- Rob
>>
>>
>>
>>> >
>>> > 3) Create connector twice makes dispatch router crash. I don't have the
>>> issue when creating addresses.
>>> > On the second create call, JMS client receives a normal reply
>>> containing a statusCode of an exception. After I close the connection to
>>> the dispatch router via JMS (connection.close), I have the below crash
>>> >
>>> > (gdb) where
>>> > #0 0x00007f27194448a5 in raise () from /lib64/libc.so.6
>>> > #1 0x00007f2719446085 in abort () from /lib64/libc.so.6
>>> > #2 0x00007f27194827b7 in __libc_message () from /lib64/libc.so.6
>>> > #3 0x00007f27194880e6 in malloc_printerr () from /lib64/libc.so.6
>>> > #4 0x00007f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf
>>> expression opcode 0xf3
>>> > ) at /qpid-dispatch-0.7.0/src/hash.c:320
>>> > #5 0x00007f271a42247d in qdr_route_check_id_for_deletion_CT
>>> (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
>>> > ) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
>>> > #6 0x00007f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30,
>>> action=Unhandled dwarf expression opcode 0xf3
>>> > ) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
>>> > #7 0x00007f271a423f30 in router_core_thread (arg=0x13d2d30) at
>>> /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
>>> > #8 0x00007f2719f8c851 in start_thread () from /lib64/libpthread.so.0
>>> > #9 0x00007f27194fa90d in clone () from /lib64/libc.so.6
>>> >
>>> >
>>> > Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE:
>>> org.apache.qpid.dispatch.connector: Duplicate value 'connector/
>>> 127.0.0.1:5915:dispatch_management_connector_test' for unique attribute
>>> 'identity'
>>> > *** glibc detected *** /Dispatch/sbin/qdrouterd: double free or
>>> corruption (fasttop): 0x00007f2708033f10 ***
>>> > ======= Backtrace: =========
>>> > /lib64/libc.so.6(+0x760e6)[0x7f27194880e6]
>>> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>>> .so(qd_hash_remove_by_handle+0x29)[0x7f271a40f109]
>>> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>>> .so(+0x3547d)[0x7f271a42247d]
>>> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>>> .so(+0x318d3)[0x7f271a41e8d3]
>>> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>>> .so(router_core_thread+0x230)[0x7f271a423f30]
>>> > /lib64/libpthread.so.0(+0x7851)[0x7f2719f8c851]
>>> > /lib64/libc.so.6(clone+0x6d)[0x7f27194fa90d]
>>> > ======= Memory map: ========
>>> > 00400000-00403000 r-xp 00000000 fd:01 7735642
>>> /Dispatch/sbin/qdrouterd
>>> > 00603000-00604000 rw-p 00003000 fd:01 7735642
>>> /Dispatch/sbin/qdrouterd
>>> > 01113000-01458000 rw-p 00000000 00:00 0
>>> [heap]
>>> > 7f26f8000000-7f26f805c000 rw-p 00000000 00:00 0
>>> > 7f26f805c000-7f26fc000000 ---p 00000000 00:00 0
>>> > 7f26fc000000-7f26fc043000 rw-p 00000000 00:00 0
>>> > 7f26fc043000-7f2700000000 ---p 00000000 00:00 0
>>> > 7f2700000000-7f2700085000 rw-p 00000000 00:00 0
>>> > 7f2700085000-7f2704000000 ---p 00000000 00:00 0
>>> > 7f27073e9000-7f27073ff000 r-xp 00000000 fd:00 524293
>>> /lib64/libgcc_s-4.4.7-20120601.so.1
>>> > 7f27073ff000-7f27075fe000 ---p 00016000 fd:00 524293
>>> /lib64/libgcc_s-4.4.7-20120601.so.1
>>> > 7f27075fe000-7f27075ff000 rw-p 00015000 fd:00 524293
>>> /lib64/libgcc_s-4.4.7-20120601.so.1
>>> > 7f27075ff000-7f2707600000 ---p 00000000 00:00 0
>>> > 7f2707600000-7f2708000000 rw-p 00000000 00:00 0
>>> > 7f2708000000-7f270805a000 rw-p 00000000 00:00 0
>>> > 7f270805a000-7f270c000000 ---p 00000000 00:00 0
>>> > 7f270c04a000-7f270c04f000 r-xp 00000000 fd:00 524322
>>> /lib64/libnss_dns-2.12.so
>>> > 7f270c04f000-7f270c24e000 ---p 00005000 fd:00 524322
>>> /lib64/libnss_dns-2.12.so
>>> > 7f270c24e000-7f270c24f000 r--p 00004000 fd:00 524322
>>> /lib64/libnss_dns-2.12.so
>>> > 7f270c24f000-7f270c250000 rw-p 00005000 fd:00 524322
>>> /lib64/libnss_dns-2.12.so
>>> > 7f270c250000-7f270c251000 ---p 00000000 00:00 0
>>> > 7f270c251000-7f270cc51000 rw-p 00000000 00:00 0
>>> > 7f270cc51000-7f270cc52000 ---p 00000000 00:00 0
>>> > 7f270cc52000-7f270d652000 rw-p 00000000 00:00 0
>>> > 7f270d652000-7f270d65e000 r-xp 00000000 fd:00 524324
>>> /lib64/libnss_files-2.12.so
>>> > 7f270d65e000-7f270d85e000 ---p 0000c000 fd:00 524324
>>> /lib64/libnss_files-2.12.so
>>> > 7f270d85e000-7f270d85f000 r--p 0000c000 fd:00 524324
>>> /lib64/libnss_files-2.12.so
>>> > 7f270d85f000-7f270d860000 rw-p 0000d000 fd:00 524324
>>> /lib64/libnss_files-2.12.so
>>> > 7f270d86a000-7f270d86b000 ---p 00000000 00:00 0
>>> > 7f270d86b000-7f270e3ac000 rw-p 00000000 00:00 0
>>> > 7f270e3ac000-7f270e3b1000 r-xp 00000000 00:16 4090944
>>> /python278/lib/python2.7/lib-dynload/select.so
>>> > 7f270e3b1000-7f270e5b0000 ---p 00005000 00:16 4090944
>>> /python278/lib/python2.7/lib-dynload/select.so
>>> > 7f270e5b0000-7f270e5b2000 rw-p 00004000 00:16 4090944
>>> /python278/lib/python2.7/lib-dynload/select.so
>>> > 7f270e5b2000-7f270e5b6000 r-xp 00000000 00:16 5568743
>>> /python278/lib/python2.7/lib-dynload/_lsprof.so
>>> > 7f270e5b6000-7f270e7b5000 ---p 00004000 00:16 5568743
>>> /python278/lib/python2.7/lib-dynload/_lsprof.so
>>> > 7f270e7b5000-7f270e7b6000 rw-p 00003000 00:16 5568743
>>> /python278/lib/python2.7/lib-dynload/_lsprof.so
>>> > 7f270e7b6000-7f270e8b7000 rw-p 00000000 00:00 0
>>> > 7f270e8b7000-7f270e8bc000 r-xp 00000000 00:16 6394000
>>> /python278/lib/python2.7/lib-dynload/strop.so
>>> > 7f270e8bc000-7f270eabb000 ---p 00005000 00:16 6394000
>>> /python278/lib/python2.7/lib-dynload/strop.so
>>> > 7f270eabb000-7f270eabd000 rw-p 00004000 00:16 6394000
>>> /python278/lib/python2.7/lib-dynload/strop.so
>>> > 7f270eabd000-7f270eafd000 rw-p 00000000 00:00 0
>>> > 7f270eafd000-7f270eb00000 r-xp 00000000 00:16 5568749
>>> /python278/lib/python2.7/lib-dynload/fcntl.so
>>> > 7f270eb00000-7f270ecff000 ---p 00003000 00:16 5568749
>>> /python278/lib/python2.7/lib-dynload/fcntl.so
>>> > 7f270ecff000-7f270ed01000 rw-p 00002000 00:16 5568749
>>> /python278/lib/python2.7/lib-dynload/fcntl.so
>>> > 7f270ed01000-7f270ed04000 r-xp 00000000 00:16 5568739
>>> /python278/lib/python2.7/lib-dynload/_random.so
>>> > 7f270ed04000-7f270ef03000 ---p 00003000 00:16 5568739
>>> /python278/lib/python2.7/lib-dynload/_random.so
>>> > 7f270ef03000-7f270ef04000 rw-p 00002000 00:16 5568739
>>> /python278/lib/python2.7/lib-dynload/_random.so
>>> > 4272 Aborted (core dumped)
>>> >
>>> >
>>> > Regards,
>>> > Adel
>>> >
>>> >
>>> > ________________________________
>>> > From: Rob Godfrey <ro...@gmail.com>
>>> > Sent: Monday, February 6, 2017 7:09 PM
>>> > To: users@qpid.apache.org
>>> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>> >
>>> > On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
>>> > wrote:
>>> >
>>> >> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com>
>>> wrote:
>>> >> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
>>> >> >
>>> >> >> It seems odd that the client creates a _sender_ to the temporary
>>> queue
>>> >> >> that it will never send messages _to_ but will receive messages
>>> _from_.
>>> >> >>
>>> >> >>
>>> >> > This is because JMS semantics require the temporary node to have a
>>> >> lifetime
>>> >> > scoped to the session (not a link), so the JMS client has to create a
>>> >> > synthetic link which it uses simply to manage the lifetime of the
>>> dynamic
>>> >> > node. In order to not cause unintentional assigning of messages to a
>>> >> link
>>> >> > that will never actually be used for consumption, a sending link is
>>> used.
>>> >> > Note that in general JMS would expect that you should be able to send
>>> to
>>> >> a
>>> >> > temporary queue created in this way (since the point of temporary
>>> queues
>>> >> is
>>> >> > to use as a reply to)
>>> >> >
>>> >>
>>> >> Not really important here, but the lifetime is scoped to the
>>> >> Connection, not Session (agghhh JMS... :P)
>>> >>
>>> >
>>> > That's what I thought I was typing... obviously my fingers were not
>>> > cooperating with my brain at that point :-)
>>> >
>>> > -- Rob
>>> >
>>> >
>>> >>
>>> >> >
>>> >> >> Anyway, when the client creates a receiver with a dynamic source
>>> (and no
>>> >> >> dynamic-node-properties), the router will accept the link and assign
>>> a
>>> >> >> temporary address as the source. This is only useful in this use
>>> case
>>> >> if
>>> >> >> the broker has a way of knowing that the temporary address is
>>> reachable
>>> >> via
>>> >> >> the router network.
>>> >> >>
>>> >> >> There is a way to route dynamic termini to a broker. If an
>>> >> >> x-opt-qd.address property is included in the dynamic-node-properties,
>>> >> this
>>> >> >> address will be used to route the attach to the broker. I've never
>>> >> tested
>>> >> >> this with a dynamic target in a sender. It might not work.
>>> >> >
>>> >> >
>>> >> > And this really isn't something you'd be expecting a generic client
>>> (like
>>> >> > the JMS client) to know :-)
>>> >> >
>>> >> > -- Rob
>>> >> >
>>> >> >
>>> >> >>
>>> >> >>
>>> >> >> -Ted
>>> >> >>
>>> >> >>
>>> >> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
>>> >> >>
>>> >> >>> I've had a look at this. It would seem that Dispatch doesn't like
>>> what
>>> >> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
>>> >> >>> very nice way, and the client then doesnt notice that things have
>>> gone
>>> >> >>> south in a somewhat unexpected way.
>>> >> >>>
>>> >> >>> The client opens a sending link with 'dynamic' target in order to
>>> >> >>> create a dynamic node for use as a TemporaryQueue
>>> address/destination
>>> >> >>> object, which specific consumers/producers are then created against
>>> by
>>> >> >>> the application. Dispatch doesn't seem to like that but erroneously
>>> >> >>> attaches the link 'successfully', though doesnt set a target address
>>> >> >>> as is expected. The client then doesnt notice this happened (its
>>> >> >>> checking for the link being refused, which it wasn't), allowing the
>>> >> >>> application to proceed as far as creating consumers/procuers using
>>> the
>>> >> >>> TemporaryQueue object, with creation of the e.g Consumer then
>>> failing
>>> >> >>> since the attach doesnt contain the needed information and leads to
>>> >> >>> Dispatch detaching it with the error (though it again doesnt
>>> actually
>>> >> >>> indicate its refusing the link during the attach response, as it
>>> >> >>> probably should have in this case).
>>> >> >>>
>>> >> >>> Making the client detect the current failure and having it throw an
>>> >> >>> aexception from createTemporaryQueue is simple enough.
>>> >> >>>
>>> >> >>> Hacking the client to use a dynamic recieving link instead, an
>>> address
>>> >> >>> was returned by Dispatch in the attach response as expected,
>>> however a
>>> >> >>> consumer on the resulting TemporaryQueue object using this address
>>> >> >>> still didnt get the message I sent to the same place. If I also gave
>>> >> >>> some credit on the link backing the TemporaryQeueue object itself
>>> then
>>> >> >>> that link gets sent the message by Dispatch, though this of no use
>>> for
>>> >> >>> the JMS client.
>>> >> >>>
>>> >> >>> Needs some more investigation, and I'll need to discuss with some
>>> >> >>> folks more familiar with Dispatch.
>>> >> >>>
>>> >> >>> Robbie
>>> >> >>>
>>> >> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
>>> >> wrote:
>>> >> >>>
>>> >> >>>> Hello Robbie,
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the
>>> reply
>>> >> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS
>>> Client.
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> PS: As Rabih stated before, we are using the same connection and
>>> same
>>> >> >>>> session to create the JMSProducer for the request and the
>>> >> JMSConsumer for
>>> >> >>>> the reply.
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> Exception
>>> >> >>>> -------------------
>>> >> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed
>>> due
>>> >> to
>>> >> >>>> an unrecoverable error.
>>> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
>>> >> >>>> eConsumer.java:330)
>>> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
>>> >> >>>> sumer.java:196)
>>> >> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
>>> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>>> >> >>>> ssorImpl.java:62)
>>> >> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>> >> >>>> thodAccessorImpl.java:43)
>>> >> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>> >> >>>> at com.intellij.rt.execution.application.AppMain.main(
>>> >> AppMain.java:147)
>>> >> >>>> Caused by: javax.jms.JMSException: No route to the destination node
>>> >> >>>> [condition = qd:no-route-to-dest]
>>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>>> >> >>>> tion(AmqpSupport.java:150)
>>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>>> >> >>>> tion(AmqpSupport.java:105)
>>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
>>> >> >>>> elyClosed(AmqpAbstractResource.java:147)
>>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
>>> >> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
>>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
>>> >> >>>> s(AmqpProvider.java:795)
>>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
>>> >> >>>> mqpProvider.java:90)
>>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
>>> >> >>>> ovider.java:699)
>>> >> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
>>> >> >>>> Executors.java:511)
>>> >> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>>> >> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>>> >> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
>>> >> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>> >> >>>> Executor.java:1142)
>>> >> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>> >> >>>> lExecutor.java:617)
>>> >> >>>> at java.lang.Thread.run(Thread.java:745)
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> -------------------
>>> >> >>>> Dispatch Router (PN_TRACE_FRM=1)
>>> >> >>>> -------------------
>>> >> >>>>
>>> >> >>>> [832220]: <- SASL
>>> >> >>>> [832220]: -> SASL
>>> >> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
>>> >> >>>> MBOL[:ANONYMOUS]]
>>> >> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
>>> >> >>>> initial-response=b"", hostname="host-name"]
>>> >> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
>>> >> >>>> [832220]: <- AMQP
>>> >> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
>>> >> a334-44c3-954a-2dd910161411:1",
>>> >> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
>>> >> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
>>> >> >>>> L[:"sole-connection-for-container"],
>>> properties={:product="QpidJMS",
>>> >> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
>>> >> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
>>> >> >>>> [832220]: -> AMQP
>>> >> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
>>> >> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
>>> >> >>>> offered-capabilities=:"ANONYMOUS-RELAY",
>>> properties={:product="qpid-
>>> >> dispatch-router",
>>> >> >>>> :version="0.7.0"}]
>>> >> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>>> >> >>>> outgoing-window=2147483647, handle-max=65535]
>>> >> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
>>> >> >>>> incoming-window=61, outgoing-window=2147483647]
>>> >> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>>> >> >>>> outgoing-window=2147483647, handle-max=65535]
>>> >> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
>>> >> >>>> incoming-window=61, outgoing-window=2147483647]
>>> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
>>> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>>> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
>>> source=@source(40)
>>> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
>>> durable=0,
>>> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>>> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list",
>>> :"amqp:rejected:list"]],
>>> >> >>>> target=@target(41) [address="$management", durable=0,
>>> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>>> >> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
>>> >> >>>> initial-delivery-count=0]
>>> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
>>> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>>> >> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>>> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
>>> durable=0,
>>> >> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:acc
>>> epted:list",
>>> >> >>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
>>> >> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
>>> >> queue]],
>>> >> >>>> initial-delivery-count=0, max-message-size=0]
>>> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>>> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>>> >> delivery-count=0,
>>> >> >>>> link-credit=250, drain=false]
>>> >> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
>>> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
>>> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
>>> source=@source(40)
>>> >> [],
>>> >> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
>>> >> timeout=0,
>>> >> >>>> dynamic=true, dynamic-node-properties={:"lif
>>> >> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
>>> >> temporary-queue"]],
>>> >> >>>> incomplete-unsettled=false, initial-delivery-count=0]
>>> >> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
>>> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
>>> >> role=true,
>>> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>>> [durable=0,
>>> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
>>> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
>>> >> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43)
>>> []},
>>> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
>>> >> initial-delivery-count=0,
>>> >> >>>> max-message-size=0]
>>> >> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>>> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>>> >> delivery-count=0,
>>> >> >>>> link-credit=250, drain=false]
>>> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
>>> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
>>> role=true,
>>> >> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
>>> [durable=0,
>>> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
>>> >> >>>> default-outcome=@modified(39) [delivery-failed=true],
>>> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
>>> >> >>>> :"amqp:released:list", :"amqp:modified:list"],
>>> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41)
>>> []]
>>> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
>>> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
>>> role=false,
>>> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>>> [durable=0,
>>> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
>>> timeout=0,
>>> >> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
>>> >> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
>>> >> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
>>> >> >>>> destination node"]]
>>> >> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
>>> >> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
>>> >> delivery-tag=b"0",
>>> >> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
>>> >> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
>>> >> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
>>> >> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
>>> >> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
>>> >> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
>>> >> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
>>> >> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
>>> >> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
>>> >> >>>> x04addr\xa1\x0dbrokerMachine"
>>> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
>>> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>>> >> delivery-count=1,
>>> >> >>>> link-credit=250, drain=false]
>>> >> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
>>> >> >>>> settled=true, state=@accepted(36) []]
>>> >> >>>> [832220]:0 <- @close(24) []
>>> >> >>>> [832220]: <- EOS
>>> >> >>>> [832220]:0 -> @close(24) []
>>> >> >>>> [832220]: -> EOS
>>> >> >>>> Closed x.x.x.x:8961
>>> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
>>> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
>>> >> >>>>
>>> >> >>>> ------------------
>>> >> >>>> JMS Client (PN_TRACE_FRM=1)
>>> >> >>>> ------------------
>>> >> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
>>> >> 4a22-9b22-69d27a017a83:1',
>>> >> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
>>> >> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
>>> >> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
>>> >> connection-for-container],
>>> >> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM:
>>> 1.8.0_111,
>>> >> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
>>> >> >>>> [1244186219:0] <- Open{ containerId='router.10200',
>>> hostname='null',
>>> >> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
>>> >> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
>>> >> ANONYMOUS-RELAY],
>>> >> >>>> desiredCapabilities=null, properties={product=qpid-dispa
>>> tch-router,
>>> >> >>>> version=0.7.0}}
>>> >> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
>>> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>>> properties=null}
>>> >> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
>>> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>>> properties=null}
>>> >> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
>>> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>>> properties=null}
>>> >> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
>>> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>>> properties=null}
>>> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
>>> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
>>> handle=0,
>>> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
>>> >> 3293ffc57168:1:1:1',
>>> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>>> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
>>> >> amqp:rejected:list],
>>> >> >>>> capabilities=null}, target=Target{address='$management',
>>> >> durable=NONE,
>>> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>>> >> maxMessageSize=null,
>>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>>> properties=null}
>>> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
>>> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
>>> handle=0,
>>> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
>>> >> 3293ffc57168:1:1:1',
>>> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>>> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
>>> >> amqp:rejected:list],
>>> >> >>>> capabilities=null}, target=Target{address='$management',
>>> >> durable=NONE,
>>> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>>> maxMessageSize=0,
>>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>>> properties=null}
>>> >> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
>>> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>>> >> deliveryCount=0,
>>> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
>>> >> properties=null}
>>> >> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
>>> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>>> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>> >> >>>> source=Source{address='null', durable=NONE,
>>> expiryPolicy=SESSION_END,
>>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>>> >> outcomes=null,
>>> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>>> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>>> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>>> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
>>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>>> >> maxMessageSize=null,
>>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>>> properties=null}
>>> >> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
>>> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>>> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>> >> >>>> source=Source{address='null', durable=NONE,
>>> expiryPolicy=SESSION_END,
>>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>>> >> outcomes=null,
>>> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>>> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>>> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>>> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
>>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>>> maxMessageSize=0,
>>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>>> properties=null}
>>> >> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
>>> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>>> >> deliveryCount=0,
>>> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
>>> >> properties=null}
>>> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
>>> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>>> >> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>> >> >>>> source=Source{address='null', durable=NONE,
>>> expiryPolicy=LINK_DETACH,
>>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>> >> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
>>> >> deliveryFailed=true,
>>> >> >>>> undeliverableHere=null, messageAnnotations=null},
>>> >> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list,
>>> amqp:released:list,
>>> >> >>>> amqp:modified:list], capabilities=[temporary-queue]},
>>> >> >>>> target=Target{address='null', durable=NONE,
>>> expiryPolicy=SESSION_END,
>>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>> >> capabilities=null},
>>> >> >>>> unsettled=null, incompleteUnsettled=false,
>>> initialDeliveryCount=null,
>>> >> >>>> maxMessageSize=null, offeredCapabilities=null,
>>> >> desiredCapabilities=null,
>>> >> >>>> properties=null}
>>> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
>>> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>>> >> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>> >> >>>> source=Source{address='null', durable=NONE,
>>> expiryPolicy=SESSION_END,
>>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>>> >> outcomes=null,
>>> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>>> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> >> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
>>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>>> maxMessageSize=0,
>>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>>> properties=null}
>>> >> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
>>> >> >>>> error=Error{condition=qd:no-route-to-dest, description='No route
>>> to
>>> >> the
>>> >> >>>> destination node', info=null}}
>>> >> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
>>> >> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
>>> >> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
>>> >> state=null,
>>> >> >>>> resume=false, aborted=false, batchable=false} (312)
>>> >> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
>>> >> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
>>> >> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$man
>>> agement@
>>> >> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
>>> >> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
>>> >> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
>>> >> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
>>> >> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
>>> >> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
>>> >> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
>>> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>>> >> deliveryCount=1,
>>> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
>>> >> properties=null}
>>> >> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
>>> >> >>>> settled=true, state=Accepted{}, batchable=false}
>>> >> >>>> [1244186219:0] -> Close{error=null}
>>> >> >>>> [1244186219:0] <- Close{error=null}
>>> >> >>>>
>>> >> >>>> Regards,
>>> >> >>>>
>>> >> >>>> Adel
>>> >> >>>>
>>> >> >>>> ________________________________
>>> >> >>>> From: Robbie Gemmell <ro...@gmail.com>
>>> >> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
>>> >> >>>> To: users@qpid.apache.org
>>> >> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>> >> >>>>
>>> >> >>>> That looks fine at first glance. Its possible there is an issue in
>>> >> >>>> there needing looked it. I am travelling this week so may not get
>>> to
>>> >> >>>> look until afterwards, but will try to give things a look at. If
>>> you
>>> >> >>>> could give more detail on the exception and maybe a protocol trace
>>> >> >>>> that might be useful.
>>> >> >>>>
>>> >> >>>> Robbie
>>> >> >>>>
>>> >> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com>
>>> wrote:
>>> >> >>>>
>>> >> >>>>> Hello Robbie,
>>> >> >>>>>
>>> >> >>>>> Thanks for you for your answer.
>>> >> >>>>> I will try the solutions you proposed.
>>> >> >>>>>
>>> >> >>>>> I need just need one clarification. Concerning the Jms, I already
>>> >> tried
>>> >> >>>>> to
>>> >> >>>>> use a temporary queue but it didn't work. May be i am using it
>>> wrong.
>>> >> >>>>> Here
>>> >> >>>>> is what i did:
>>> >> >>>>>
>>> >> >>>>> ...
>>> >> >>>>> Session session = connection.createSession(false,
>>> >> >>>>> Session.AUTO_ACKNOWLEDGE);
>>> >> >>>>> Queue queue = session.createQueue("$management");
>>> >> >>>>> MessageProducer producer = session.createProducer(queue);
>>> >> >>>>>
>>> >> >>>>> Queue tempDest = session.createTemporaryQueue();
>>> >> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDes
>>> t);
>>> >> >>>>> connection.start();
>>> >> >>>>>
>>> >> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
>>> >> >>>>> objectMessage.setJMSReplyTo(tempDest);
>>> >> >>>>> //fill the rest of the parameters ...
>>> >> >>>>> producer.send(objectMessage);
>>> >> >>>>> ObjectMessage replyMessage = (ObjectMessage)
>>> >> >>>>> responseConsumer.receive(1000);
>>> >> >>>>> ...
>>> >> >>>>>
>>> >> >>>>> I was getting an exception on the .receive() from the dispatch
>>> router
>>> >> >>>>> saying that the reply-to address is bad...
>>> >> >>>>> Should i create the temporary queue and the consumer from a
>>> different
>>> >> >>>>> session then the producer?
>>> >> >>>>>
>>> >> >>>>> Best regards,
>>> >> >>>>> Rabih
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
>>> >> >>>>> robbie.gemmell@gmail.com>
>>> >> >>>>> wrote:
>>> >> >>>>>
>>> >> >>>>> The session.createTemporaryQueue(); method is how JMS creates
>>> >> >>>>>> temporary destinations for use in reply-to scenarios. The
>>> dispatch
>>> >> >>>>>> tools will be doing essentially the same thing under the covers
>>> for
>>> >> >>>>>> theirs.
>>> >> >>>>>>
>>> >> >>>>>> Both work by creating a 'dynamic' link attachment, with the
>>> server
>>> >> >>>>>> returning an address for the dynamic attach to the client. One
>>> key
>>> >> >>>>>> difference is with JMS you create the temporary destination (for
>>> >> which
>>> >> >>>>>> the client uses a dynamic sender link to create), then separately
>>> >> >>>>>> create a receiver using it (and in turn the address associated
>>> with
>>> >> >>>>>> it), whereas non-JMS client/tools will typically just create a
>>> >> single
>>> >> >>>>>> dynamic receiver link and use its address for the reply-to.
>>> >> >>>>>>
>>> >> >>>>>> For proton-j, there aren't any examples for this, but you you
>>> >> >>>>>> essentially would change the link opening to not specify an
>>> address,
>>> >> >>>>>> and instead set the source(for a receiver) or target (for a
>>> sender)
>>> >> to
>>> >> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
>>> >> remoteTarget
>>> >> >>>>>> once the link had been reemotely attached, and get its
>>> >> >>>>>> (server-generated) address, then use this as your reply-to.
>>> >> >>>>>>
>>> >> >>>>>> Robbie
>>> >> >>>>>>
>>> >> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
>>> >> wrote:
>>> >> >>>>>>
>>> >> >>>>>>> Hello,
>>> >> >>>>>>>
>>> >> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like
>>> you
>>> >> >>>>>>> suggested, it worked.
>>> >> >>>>>>> But I cheated a little to make it work because I did not find a
>>> >> way in
>>> >> >>>>>>>
>>> >> >>>>>> JMS
>>> >> >>>>>>
>>> >> >>>>>>> to create a local queue. So I created a queue on the
>>> qpid-dispatch
>>> >> and
>>> >> >>>>>>>
>>> >> >>>>>> read
>>> >> >>>>>>
>>> >> >>>>>>> the result from it. You can check the attached code.
>>> >> >>>>>>>
>>> >> >>>>>>> Is there any way using qpid-jms to create a local queue on the
>>> >> client
>>> >> >>>>>>>
>>> >> >>>>>> side
>>> >> >>>>>>
>>> >> >>>>>>> to serve as a reply to address?
>>> >> >>>>>>>
>>> >> >>>>>>> For the proton-j test, I have the same question as above. I saw
>>> >> that
>>> >> >>>>>>> it
>>> >> >>>>>>>
>>> >> >>>>>> can
>>> >> >>>>>>
>>> >> >>>>>>> be done with the C++ API. Are there any examples for proton-j or
>>> >> >>>>>>>
>>> >> >>>>>> something
>>> >> >>>>>>
>>> >> >>>>>>> that can help me?
>>> >> >>>>>>>
>>> >> >>>>>>> I saw may be in proton we don't need a local queue, may be we
>>> can
>>> >> get
>>> >> >>>>>>> the
>>> >> >>>>>>> address of the consumer directly and pass it in reply-to field.
>>> Is
>>> >> it
>>> >> >>>>>>> correct?
>>> >> >>>>>>>
>>> >> >>>>>>> Thanks,
>>> >> >>>>>>> Rabih
>>> >> >>>>>>>
>>> >> >>>>>>>
>>> >> >>>>>>>
>>> >> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
>>> >> >>>>>>> rob.j.godfrey@gmail.com>
>>> >> >>>>>>> wrote:
>>> >> >>>>>>>
>>> >> >>>>>>>>
>>> >> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gmurthy@redhat.com
>>> >
>>> >> >>>>>>>> wrote:
>>> >> >>>>>>>>
>>> >> >>>>>>>>
>>> >> >>>>>>>>>
>>> >> >>>>>>>>> ----- Original Message -----
>>> >> >>>>>>>>>
>>> >> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
>>> >> >>>>>>>>>> To: users@qpid.apache.org
>>> >> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
>>> >> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid
>>> >> Jms
>>> >> >>>>>>>>>>
>>> >> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
>>> >> wrote:
>>> >> >>>>>>>>>>
>>> >> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
>>> >> >>>>>>>>>>>
>>> >> >>>>>>>>>>>>
>>> >> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you
>>> >> told
>>> >> >>>>>>>>>>>>
>>> >> >>>>>>>>>>> me
>>> >> >>>>>>
>>> >> >>>>>>> Robbie and it worked.
>>> >> >>>>>>>>>>>>
>>> >> >>>>>>>>>>>> But like the proton-j case, the connector is not being
>>> >> created on
>>> >> >>>>>>>>>>>> the
>>> >> >>>>>>>>>>>> Qpid-dispatch side.
>>> >> >>>>>>>>>>>> I attached the amqp communication into this mail.
>>> >> >>>>>>>>>>>>
>>> >> >>>>>>>>>>>
>>> >> >>>>>>>>>>>
>>> >> >>>>>>>>>>> The last frame in that file is incomplete (the previous
>>> error
>>> >> >>>>>>>>>>>
>>> >> >>>>>>>>>> regarding the
>>> >> >>>>>>>>>
>>> >> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
>>> >> frame
>>> >> >>>>>>>>>>>
>>> >> >>>>>>>>>> is
>>> >> >>>>>>
>>> >> >>>>>>> likely
>>> >> >>>>>>>>>
>>> >> >>>>>>>>>> the response which would indicate the success or otherwise of
>>> >> the
>>> >> >>>>>>>>>>>
>>> >> >>>>>>>>>> frame. Is
>>> >> >>>>>>>>>
>>> >> >>>>>>>>>> there anything logged by the router?
>>> >> >>>>>>>>>>>
>>> >> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
>>> >> simpler
>>> >> >>>>>>>>>>> for
>>> >> >>>>>>>>>>>
>>> >> >>>>>>>>>> this
>>> >> >>>>>>>>>
>>> >> >>>>>>>>>> sort of thing in my view.
>>> >> >>>>>>>>>>>
>>> >> >>>>>>>>>>>
>>> >> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more
>>> helpful.
>>> >> >>>>>>>>>> You
>>> >> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
>>> >> since
>>> >> >>>>>>>>>> it
>>> >> >>>>>>>>>> uses proton-j.
>>> >> >>>>>>>>>>
>>> >> >>>>>>>>>> One key difference from the qdmanage case is you are not
>>> >> setting a
>>> >> >>>>>>>>>> reply-to value or correlation-id to use along with it. I
>>> don't
>>> >> know
>>> >> >>>>>>>>>>
>>> >> >>>>>>>>> if
>>> >> >>>>>>
>>> >> >>>>>>> the router cares about not being able to send a response or not
>>> >> >>>>>>>>>> though, but it might.
>>> >> >>>>>>>>>>
>>> >> >>>>>>>>>
>>> >> >>>>>>>>> You could add the following to your dispatch router conf file
>>> >> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable
>>> trace
>>> >> >>>>>>>>>
>>> >> >>>>>>>> logging)
>>> >> >>>>>>
>>> >> >>>>>>>
>>> >> >>>>>>>>> log {
>>> >> >>>>>>>>> module: DEFAULT
>>> >> >>>>>>>>> enable: trace+
>>> >> >>>>>>>>> output: /path/to/log/qdrouterd.log
>>> >> >>>>>>>>> }
>>> >> >>>>>>>>>
>>> >> >>>>>>>>> When you run your management request, you will see proton
>>> frame
>>> >> >>>>>>>>> trace
>>> >> >>>>>>>>> and
>>> >> >>>>>>>>> you will see additional logging out of the dispatch Python
>>> agent
>>> >> -
>>> >> >>>>>>>>> something like the following -
>>> >> >>>>>>>>>
>>> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>>> >> >>>>>>>>> Message(address=None,
>>> >> >>>>>>>>> properties={'operation': 'CREATE', 'type':
>>> >> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
>>> >> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>>> >> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
>>> >> >>>>>>>>>
>>> >> >>>>>>>> 'rabih.connector'},
>>> >> >>>>>>
>>> >> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>>> >> >>>>>>>>> correlation_id=1L)
>>> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>>> >> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
>>> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>>> >> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True,
>>> cost=1,
>>> >> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
>>> >> 5673:rabih.connector,
>>> >> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>>> >> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
>>> >> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.
>>> connector,
>>> >> >>>>>>>>> verifyHostName=True)
>>> >> >>>>>>>>>
>>> >> >>>>>>>>> The Python management agent will not process your request if
>>> >> there
>>> >> >>>>>>>>> is
>>> >> >>>>>>>>>
>>> >> >>>>>>>> no
>>> >> >>>>>>
>>> >> >>>>>>> reply_to as seen here -
>>> >> >>>>>>>>>
>>> >> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
>>> >> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
>>> >> >>>>>>>>>
>>> >> >>>>>>>>>
>>> >> >>>>>>>>>
>>> >> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
>>> >> because
>>> >> >>>>>>>> there
>>> >> >>>>>>>> is
>>> >> >>>>>>>> a reply-to doesn't mean that the sender will be around to
>>> actually
>>> >> >>>>>>>> hear
>>> >> >>>>>>>> the
>>> >> >>>>>>>> reply, so it seems a bit arbitrary to say that because we
>>> *know*
>>> >> the
>>> >> >>>>>>>> sender
>>> >> >>>>>>>> won't learn of the outcome that we won't do anything... The
>>> spec
>>> >> >>>>>>>> draft
>>> >> >>>>>>>> doesn't currently say anything about this (obviously it should
>>> >> do),
>>> >> >>>>>>>> but
>>> >> >>>>>>>>
>>> >> >>>>>>> my
>>> >> >>>>>>
>>> >> >>>>>>> expectation would certainly be that a request would be processed
>>> >> even
>>> >> >>>>>>>> if
>>> >> >>>>>>>> the replyTo address was not present (or ended up not routing
>>> >> >>>>>>>> anywhere).
>>> >> >>>>>>>> This is also how the Qpid Broker for Java implements this case.
>>> >> >>>>>>>>
>>> >> >>>>>>>> -- Rob
>>> >> >>>>>>>>
>>> >> >>>>>>>>
>>> >> >>>>>>>> Thanks.
>>> >> >>>>>>>>>
>>> >> >>>>>>>>>
>>> >> >>>>>>>>>> Robbie
>>> >> >>>>>>>>>>
>>> >> >>>>>>>>>> ------------------------------------------------------------
>>> >> >>>>>>>>>>
>>> >> >>>>>>>>> ---------
>>> >> >>>>>>
>>> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>> >> >>>>>>>>>>
>>> >> >>>>>>>>>>
>>> >> >>>>>>>>>>
>>> >> >>>>>>>>> ------------------------------------------------------------
>>> >> >>>>>>>>> ---------
>>> >> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>> >> >>>>>>>>>
>>> >> >>>>>>>>>
>>> >> >>>>>>>>>
>>> >> >>>>>>>
>>> >> >>>>>>>
>>> >> >>>>>>>
>>> >> >>>>>>> ------------------------------------------------------------
>>> >> ---------
>>> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>> >> >>>>>>>
>>> >> >>>>>>
>>> >> >>>>>> ------------------------------------------------------------
>>> >> ---------
>>> >> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>> ------------------------------------------------------------
>>> ---------
>>> >> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> >>>> For additional commands, e-mail: users-help@qpid.apache.org
>>> >> >>>>
>>> >> >>>>
>>> >> >>> ------------------------------------------------------------
>>> ---------
>>> >> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> >>> For additional commands, e-mail: users-help@qpid.apache.org
>>> >> >>>
>>> >> >>>
>>> >> >> ------------------------------------------------------------
>>> ---------
>>> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> >> For additional commands, e-mail: users-help@qpid.apache.org
>>> >> >>
>>> >> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> For additional commands, e-mail: users-help@qpid.apache.org
>>> >>
>>> >>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Adel Boutros <Ad...@live.com>.
Thank you Robbie.
So If I understood correctly, in the next release of the components (Dispatch, Proton, JMS), the below is correctly supported because you tested on the Master branches. Right?
Regards,
Adel
________________________________
From: Robbie Gemmell <ro...@gmail.com>
Sent: Friday, February 24, 2017 5:43:05 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
I tried this (modified to use a temporary queue) and also modified the
Qpid JMS HelloWorld example to use a temporary queue, and ran both
against the router successfully multiple times, using the jms client
from master, dispatch from master, and proton from master.
The only odd thing was that Dispatch printed out two copies of notices
about the connection closing without the links being explicitly
detached, which is what the examples do and not something I would
consider unusual. I wouldnt really expect to see these notices, but if
so then only one copy.
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
due to parent connection end
As an aside, the typical TemporaryQueue usage would be just to use the
destination object directly, i.e the below, not ask its name and
create another destination with that name. I tried both ways just to
check it wasnt related though and they both worked the same.
TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
managementConsumer = managementSession.createConsumer(temporaryQueue);
On 22 February 2017 at 11:33, Adel Boutros <Ad...@live.com> wrote:
> Hello guys,
>
>
> My basic JMS API is almost ready. I will share it with you soon to have your feedback.
>
>
> However, I tried one last thing by getting a random queue name and using it as management reply queue to allow multiple configuration sessions simultaneously but it didn't work.
>
>
> //This doesn't work and crashes the dispatch router
>
> TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
> replyToQueue = managementSession.createQueue(temporaryQueue.getQueueName());
> managementConsumer = managementSession.createConsumer(replyToQueue);
>
> //This is the only thing working
> replyToQueue = managementSession.createQueue("HARD_CODED_REPLY_QUEUE");
> managementConsumer = managementSession.createConsumer(replyToQueue);
>
>
> Can I have your input on the above?
>
> Regards,
> Adel
>
>
> ________________________________
> From: Rob Godfrey <ro...@gmail.com>
> Sent: Wednesday, February 15, 2017 4:46:59 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> On 15 February 2017 at 16:07, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> On 15 February 2017 at 14:15, Adel Boutros <Ad...@live.com> wrote:
>> > Hello guys,
>> >
>> >
>> > Based on the discussion, we are currently writing a Java API based on
>> JMS to configure the dispatch router. I have so far managed to do the
>> following:
>> >
>> > * Create, Read, Delete addresses
>> >
>> > * Create, Read, Delete connectors
>> >
>> >
>> > Config:
>> >
>> > Dispatch Router 0.7.0
>> >
>> > JMS 0.11.1
>> >
>> >
>> > And I have noticed some problems and differences:
>> >
>> >
>> > 1) It seems some calls return ObjectMessage and some TextMessage (This
>> is on the side of the consumer in the replyTo)
>> >
>> > For example, creating twice the same queue will fail but the second call
>> will return a JmsTextMessage with an empty body and status code 400
>> >
>>
>> The client treats messages with an amqp-value sectioning containing
>> null/nothing as a TextMessage with null value if they arent annotated
>> to say otherwise, I'd guess thats where that comes from.
>>
>> >
>> > 2) Returned statusCode differs between Connector and Address
>> >
>> > Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
>> >
>> >
>> > * Connector operations return java.lang.Long
>> > * Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
>> >
>>
>> The router is presumably sending different values back for the
>> different operations here, a long and a uint. The router should
>> perhaps be consistent, and the client should perhaps not be returning
>> the uint object either way.
>>
>> The last draft of the management spec seems to say the status code
>> should be 'integer', im not clear if it means int (not uint)
>> specifically, or just any integral type value.
>>
>>
> The specification should definitely say which type should - so we'll fix
> that in the next draft. I'd suggest we should int (in AMQP terms) leading
> to a java.lang.Integer type in the property you see through Java.
>
> -- Rob
>
>
>
>> >
>> > 3) Create connector twice makes dispatch router crash. I don't have the
>> issue when creating addresses.
>> > On the second create call, JMS client receives a normal reply
>> containing a statusCode of an exception. After I close the connection to
>> the dispatch router via JMS (connection.close), I have the below crash
>> >
>> > (gdb) where
>> > #0 0x00007f27194448a5 in raise () from /lib64/libc.so.6
>> > #1 0x00007f2719446085 in abort () from /lib64/libc.so.6
>> > #2 0x00007f27194827b7 in __libc_message () from /lib64/libc.so.6
>> > #3 0x00007f27194880e6 in malloc_printerr () from /lib64/libc.so.6
>> > #4 0x00007f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf
>> expression opcode 0xf3
>> > ) at /qpid-dispatch-0.7.0/src/hash.c:320
>> > #5 0x00007f271a42247d in qdr_route_check_id_for_deletion_CT
>> (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
>> > ) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
>> > #6 0x00007f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30,
>> action=Unhandled dwarf expression opcode 0xf3
>> > ) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
>> > #7 0x00007f271a423f30 in router_core_thread (arg=0x13d2d30) at
>> /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
>> > #8 0x00007f2719f8c851 in start_thread () from /lib64/libpthread.so.0
>> > #9 0x00007f27194fa90d in clone () from /lib64/libc.so.6
>> >
>> >
>> > Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE:
>> org.apache.qpid.dispatch.connector: Duplicate value 'connector/
>> 127.0.0.1:5915:dispatch_management_connector_test' for unique attribute
>> 'identity'
>> > *** glibc detected *** /Dispatch/sbin/qdrouterd: double free or
>> corruption (fasttop): 0x00007f2708033f10 ***
>> > ======= Backtrace: =========
>> > /lib64/libc.so.6(+0x760e6)[0x7f27194880e6]
>> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>> .so(qd_hash_remove_by_handle+0x29)[0x7f271a40f109]
>> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>> .so(+0x3547d)[0x7f271a42247d]
>> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>> .so(+0x318d3)[0x7f271a41e8d3]
>> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>> .so(router_core_thread+0x230)[0x7f271a423f30]
>> > /lib64/libpthread.so.0(+0x7851)[0x7f2719f8c851]
>> > /lib64/libc.so.6(clone+0x6d)[0x7f27194fa90d]
>> > ======= Memory map: ========
>> > 00400000-00403000 r-xp 00000000 fd:01 7735642
>> /Dispatch/sbin/qdrouterd
>> > 00603000-00604000 rw-p 00003000 fd:01 7735642
>> /Dispatch/sbin/qdrouterd
>> > 01113000-01458000 rw-p 00000000 00:00 0
>> [heap]
>> > 7f26f8000000-7f26f805c000 rw-p 00000000 00:00 0
>> > 7f26f805c000-7f26fc000000 ---p 00000000 00:00 0
>> > 7f26fc000000-7f26fc043000 rw-p 00000000 00:00 0
>> > 7f26fc043000-7f2700000000 ---p 00000000 00:00 0
>> > 7f2700000000-7f2700085000 rw-p 00000000 00:00 0
>> > 7f2700085000-7f2704000000 ---p 00000000 00:00 0
>> > 7f27073e9000-7f27073ff000 r-xp 00000000 fd:00 524293
>> /lib64/libgcc_s-4.4.7-20120601.so.1
>> > 7f27073ff000-7f27075fe000 ---p 00016000 fd:00 524293
>> /lib64/libgcc_s-4.4.7-20120601.so.1
>> > 7f27075fe000-7f27075ff000 rw-p 00015000 fd:00 524293
>> /lib64/libgcc_s-4.4.7-20120601.so.1
>> > 7f27075ff000-7f2707600000 ---p 00000000 00:00 0
>> > 7f2707600000-7f2708000000 rw-p 00000000 00:00 0
>> > 7f2708000000-7f270805a000 rw-p 00000000 00:00 0
>> > 7f270805a000-7f270c000000 ---p 00000000 00:00 0
>> > 7f270c04a000-7f270c04f000 r-xp 00000000 fd:00 524322
>> /lib64/libnss_dns-2.12.so
>> > 7f270c04f000-7f270c24e000 ---p 00005000 fd:00 524322
>> /lib64/libnss_dns-2.12.so
>> > 7f270c24e000-7f270c24f000 r--p 00004000 fd:00 524322
>> /lib64/libnss_dns-2.12.so
>> > 7f270c24f000-7f270c250000 rw-p 00005000 fd:00 524322
>> /lib64/libnss_dns-2.12.so
>> > 7f270c250000-7f270c251000 ---p 00000000 00:00 0
>> > 7f270c251000-7f270cc51000 rw-p 00000000 00:00 0
>> > 7f270cc51000-7f270cc52000 ---p 00000000 00:00 0
>> > 7f270cc52000-7f270d652000 rw-p 00000000 00:00 0
>> > 7f270d652000-7f270d65e000 r-xp 00000000 fd:00 524324
>> /lib64/libnss_files-2.12.so
>> > 7f270d65e000-7f270d85e000 ---p 0000c000 fd:00 524324
>> /lib64/libnss_files-2.12.so
>> > 7f270d85e000-7f270d85f000 r--p 0000c000 fd:00 524324
>> /lib64/libnss_files-2.12.so
>> > 7f270d85f000-7f270d860000 rw-p 0000d000 fd:00 524324
>> /lib64/libnss_files-2.12.so
>> > 7f270d86a000-7f270d86b000 ---p 00000000 00:00 0
>> > 7f270d86b000-7f270e3ac000 rw-p 00000000 00:00 0
>> > 7f270e3ac000-7f270e3b1000 r-xp 00000000 00:16 4090944
>> /python278/lib/python2.7/lib-dynload/select.so
>> > 7f270e3b1000-7f270e5b0000 ---p 00005000 00:16 4090944
>> /python278/lib/python2.7/lib-dynload/select.so
>> > 7f270e5b0000-7f270e5b2000 rw-p 00004000 00:16 4090944
>> /python278/lib/python2.7/lib-dynload/select.so
>> > 7f270e5b2000-7f270e5b6000 r-xp 00000000 00:16 5568743
>> /python278/lib/python2.7/lib-dynload/_lsprof.so
>> > 7f270e5b6000-7f270e7b5000 ---p 00004000 00:16 5568743
>> /python278/lib/python2.7/lib-dynload/_lsprof.so
>> > 7f270e7b5000-7f270e7b6000 rw-p 00003000 00:16 5568743
>> /python278/lib/python2.7/lib-dynload/_lsprof.so
>> > 7f270e7b6000-7f270e8b7000 rw-p 00000000 00:00 0
>> > 7f270e8b7000-7f270e8bc000 r-xp 00000000 00:16 6394000
>> /python278/lib/python2.7/lib-dynload/strop.so
>> > 7f270e8bc000-7f270eabb000 ---p 00005000 00:16 6394000
>> /python278/lib/python2.7/lib-dynload/strop.so
>> > 7f270eabb000-7f270eabd000 rw-p 00004000 00:16 6394000
>> /python278/lib/python2.7/lib-dynload/strop.so
>> > 7f270eabd000-7f270eafd000 rw-p 00000000 00:00 0
>> > 7f270eafd000-7f270eb00000 r-xp 00000000 00:16 5568749
>> /python278/lib/python2.7/lib-dynload/fcntl.so
>> > 7f270eb00000-7f270ecff000 ---p 00003000 00:16 5568749
>> /python278/lib/python2.7/lib-dynload/fcntl.so
>> > 7f270ecff000-7f270ed01000 rw-p 00002000 00:16 5568749
>> /python278/lib/python2.7/lib-dynload/fcntl.so
>> > 7f270ed01000-7f270ed04000 r-xp 00000000 00:16 5568739
>> /python278/lib/python2.7/lib-dynload/_random.so
>> > 7f270ed04000-7f270ef03000 ---p 00003000 00:16 5568739
>> /python278/lib/python2.7/lib-dynload/_random.so
>> > 7f270ef03000-7f270ef04000 rw-p 00002000 00:16 5568739
>> /python278/lib/python2.7/lib-dynload/_random.so
>> > 4272 Aborted (core dumped)
>> >
>> >
>> > Regards,
>> > Adel
>> >
>> >
>> > ________________________________
>> > From: Rob Godfrey <ro...@gmail.com>
>> > Sent: Monday, February 6, 2017 7:09 PM
>> > To: users@qpid.apache.org
>> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>> >
>> > On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
>> > wrote:
>> >
>> >> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com>
>> wrote:
>> >> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
>> >> >
>> >> >> It seems odd that the client creates a _sender_ to the temporary
>> queue
>> >> >> that it will never send messages _to_ but will receive messages
>> _from_.
>> >> >>
>> >> >>
>> >> > This is because JMS semantics require the temporary node to have a
>> >> lifetime
>> >> > scoped to the session (not a link), so the JMS client has to create a
>> >> > synthetic link which it uses simply to manage the lifetime of the
>> dynamic
>> >> > node. In order to not cause unintentional assigning of messages to a
>> >> link
>> >> > that will never actually be used for consumption, a sending link is
>> used.
>> >> > Note that in general JMS would expect that you should be able to send
>> to
>> >> a
>> >> > temporary queue created in this way (since the point of temporary
>> queues
>> >> is
>> >> > to use as a reply to)
>> >> >
>> >>
>> >> Not really important here, but the lifetime is scoped to the
>> >> Connection, not Session (agghhh JMS... :P)
>> >>
>> >
>> > That's what I thought I was typing... obviously my fingers were not
>> > cooperating with my brain at that point :-)
>> >
>> > -- Rob
>> >
>> >
>> >>
>> >> >
>> >> >> Anyway, when the client creates a receiver with a dynamic source
>> (and no
>> >> >> dynamic-node-properties), the router will accept the link and assign
>> a
>> >> >> temporary address as the source. This is only useful in this use
>> case
>> >> if
>> >> >> the broker has a way of knowing that the temporary address is
>> reachable
>> >> via
>> >> >> the router network.
>> >> >>
>> >> >> There is a way to route dynamic termini to a broker. If an
>> >> >> x-opt-qd.address property is included in the dynamic-node-properties,
>> >> this
>> >> >> address will be used to route the attach to the broker. I've never
>> >> tested
>> >> >> this with a dynamic target in a sender. It might not work.
>> >> >
>> >> >
>> >> > And this really isn't something you'd be expecting a generic client
>> (like
>> >> > the JMS client) to know :-)
>> >> >
>> >> > -- Rob
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> -Ted
>> >> >>
>> >> >>
>> >> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
>> >> >>
>> >> >>> I've had a look at this. It would seem that Dispatch doesn't like
>> what
>> >> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
>> >> >>> very nice way, and the client then doesnt notice that things have
>> gone
>> >> >>> south in a somewhat unexpected way.
>> >> >>>
>> >> >>> The client opens a sending link with 'dynamic' target in order to
>> >> >>> create a dynamic node for use as a TemporaryQueue
>> address/destination
>> >> >>> object, which specific consumers/producers are then created against
>> by
>> >> >>> the application. Dispatch doesn't seem to like that but erroneously
>> >> >>> attaches the link 'successfully', though doesnt set a target address
>> >> >>> as is expected. The client then doesnt notice this happened (its
>> >> >>> checking for the link being refused, which it wasn't), allowing the
>> >> >>> application to proceed as far as creating consumers/procuers using
>> the
>> >> >>> TemporaryQueue object, with creation of the e.g Consumer then
>> failing
>> >> >>> since the attach doesnt contain the needed information and leads to
>> >> >>> Dispatch detaching it with the error (though it again doesnt
>> actually
>> >> >>> indicate its refusing the link during the attach response, as it
>> >> >>> probably should have in this case).
>> >> >>>
>> >> >>> Making the client detect the current failure and having it throw an
>> >> >>> aexception from createTemporaryQueue is simple enough.
>> >> >>>
>> >> >>> Hacking the client to use a dynamic recieving link instead, an
>> address
>> >> >>> was returned by Dispatch in the attach response as expected,
>> however a
>> >> >>> consumer on the resulting TemporaryQueue object using this address
>> >> >>> still didnt get the message I sent to the same place. If I also gave
>> >> >>> some credit on the link backing the TemporaryQeueue object itself
>> then
>> >> >>> that link gets sent the message by Dispatch, though this of no use
>> for
>> >> >>> the JMS client.
>> >> >>>
>> >> >>> Needs some more investigation, and I'll need to discuss with some
>> >> >>> folks more familiar with Dispatch.
>> >> >>>
>> >> >>> Robbie
>> >> >>>
>> >> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
>> >> wrote:
>> >> >>>
>> >> >>>> Hello Robbie,
>> >> >>>>
>> >> >>>>
>> >> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the
>> reply
>> >> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS
>> Client.
>> >> >>>>
>> >> >>>>
>> >> >>>> PS: As Rabih stated before, we are using the same connection and
>> same
>> >> >>>> session to create the JMSProducer for the request and the
>> >> JMSConsumer for
>> >> >>>> the reply.
>> >> >>>>
>> >> >>>>
>> >> >>>> Exception
>> >> >>>> -------------------
>> >> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed
>> due
>> >> to
>> >> >>>> an unrecoverable error.
>> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
>> >> >>>> eConsumer.java:330)
>> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
>> >> >>>> sumer.java:196)
>> >> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
>> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> >> >>>> ssorImpl.java:62)
>> >> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> >> >>>> thodAccessorImpl.java:43)
>> >> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
>> >> >>>> at com.intellij.rt.execution.application.AppMain.main(
>> >> AppMain.java:147)
>> >> >>>> Caused by: javax.jms.JMSException: No route to the destination node
>> >> >>>> [condition = qd:no-route-to-dest]
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>> >> >>>> tion(AmqpSupport.java:150)
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>> >> >>>> tion(AmqpSupport.java:105)
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
>> >> >>>> elyClosed(AmqpAbstractResource.java:147)
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
>> >> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
>> >> >>>> s(AmqpProvider.java:795)
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
>> >> >>>> mqpProvider.java:90)
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
>> >> >>>> ovider.java:699)
>> >> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
>> >> >>>> Executors.java:511)
>> >> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>> >> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>> >> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
>> >> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> >> >>>> Executor.java:1142)
>> >> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> >> >>>> lExecutor.java:617)
>> >> >>>> at java.lang.Thread.run(Thread.java:745)
>> >> >>>>
>> >> >>>>
>> >> >>>> -------------------
>> >> >>>> Dispatch Router (PN_TRACE_FRM=1)
>> >> >>>> -------------------
>> >> >>>>
>> >> >>>> [832220]: <- SASL
>> >> >>>> [832220]: -> SASL
>> >> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
>> >> >>>> MBOL[:ANONYMOUS]]
>> >> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
>> >> >>>> initial-response=b"", hostname="host-name"]
>> >> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
>> >> >>>> [832220]: <- AMQP
>> >> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
>> >> a334-44c3-954a-2dd910161411:1",
>> >> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
>> >> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
>> >> >>>> L[:"sole-connection-for-container"],
>> properties={:product="QpidJMS",
>> >> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
>> >> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
>> >> >>>> [832220]: -> AMQP
>> >> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
>> >> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
>> >> >>>> offered-capabilities=:"ANONYMOUS-RELAY",
>> properties={:product="qpid-
>> >> dispatch-router",
>> >> >>>> :version="0.7.0"}]
>> >> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>> >> >>>> outgoing-window=2147483647, handle-max=65535]
>> >> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
>> >> >>>> incoming-window=61, outgoing-window=2147483647]
>> >> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>> >> >>>> outgoing-window=2147483647, handle-max=65535]
>> >> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
>> >> >>>> incoming-window=61, outgoing-window=2147483647]
>> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
>> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
>> source=@source(40)
>> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
>> durable=0,
>> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list",
>> :"amqp:rejected:list"]],
>> >> >>>> target=@target(41) [address="$management", durable=0,
>> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>> >> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
>> >> >>>> initial-delivery-count=0]
>> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
>> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>> >> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
>> durable=0,
>> >> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:acc
>> epted:list",
>> >> >>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
>> >> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
>> >> queue]],
>> >> >>>> initial-delivery-count=0, max-message-size=0]
>> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>> >> delivery-count=0,
>> >> >>>> link-credit=250, drain=false]
>> >> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
>> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
>> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
>> source=@source(40)
>> >> [],
>> >> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
>> >> timeout=0,
>> >> >>>> dynamic=true, dynamic-node-properties={:"lif
>> >> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
>> >> temporary-queue"]],
>> >> >>>> incomplete-unsettled=false, initial-delivery-count=0]
>> >> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
>> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
>> >> role=true,
>> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>> [durable=0,
>> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
>> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
>> >> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43)
>> []},
>> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
>> >> initial-delivery-count=0,
>> >> >>>> max-message-size=0]
>> >> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>> >> delivery-count=0,
>> >> >>>> link-credit=250, drain=false]
>> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
>> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
>> role=true,
>> >> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
>> [durable=0,
>> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
>> >> >>>> default-outcome=@modified(39) [delivery-failed=true],
>> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
>> >> >>>> :"amqp:released:list", :"amqp:modified:list"],
>> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41)
>> []]
>> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
>> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
>> role=false,
>> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>> [durable=0,
>> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
>> timeout=0,
>> >> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
>> >> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
>> >> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
>> >> >>>> destination node"]]
>> >> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
>> >> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
>> >> delivery-tag=b"0",
>> >> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
>> >> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
>> >> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
>> >> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
>> >> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
>> >> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
>> >> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
>> >> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
>> >> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
>> >> >>>> x04addr\xa1\x0dbrokerMachine"
>> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
>> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>> >> delivery-count=1,
>> >> >>>> link-credit=250, drain=false]
>> >> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
>> >> >>>> settled=true, state=@accepted(36) []]
>> >> >>>> [832220]:0 <- @close(24) []
>> >> >>>> [832220]: <- EOS
>> >> >>>> [832220]:0 -> @close(24) []
>> >> >>>> [832220]: -> EOS
>> >> >>>> Closed x.x.x.x:8961
>> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
>> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
>> >> >>>>
>> >> >>>> ------------------
>> >> >>>> JMS Client (PN_TRACE_FRM=1)
>> >> >>>> ------------------
>> >> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
>> >> 4a22-9b22-69d27a017a83:1',
>> >> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
>> >> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
>> >> connection-for-container],
>> >> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM:
>> 1.8.0_111,
>> >> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
>> >> >>>> [1244186219:0] <- Open{ containerId='router.10200',
>> hostname='null',
>> >> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
>> >> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
>> >> ANONYMOUS-RELAY],
>> >> >>>> desiredCapabilities=null, properties={product=qpid-dispa
>> tch-router,
>> >> >>>> version=0.7.0}}
>> >> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
>> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
>> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
>> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
>> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
>> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
>> handle=0,
>> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
>> >> 3293ffc57168:1:1:1',
>> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
>> >> amqp:rejected:list],
>> >> >>>> capabilities=null}, target=Target{address='$management',
>> >> durable=NONE,
>> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> >> maxMessageSize=null,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
>> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
>> handle=0,
>> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
>> >> 3293ffc57168:1:1:1',
>> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
>> >> amqp:rejected:list],
>> >> >>>> capabilities=null}, target=Target{address='$management',
>> >> durable=NONE,
>> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> maxMessageSize=0,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
>> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>> >> deliveryCount=0,
>> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
>> >> properties=null}
>> >> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
>> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>> >> >>>> source=Source{address='null', durable=NONE,
>> expiryPolicy=SESSION_END,
>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>> >> outcomes=null,
>> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> >> maxMessageSize=null,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
>> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>> >> >>>> source=Source{address='null', durable=NONE,
>> expiryPolicy=SESSION_END,
>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>> >> outcomes=null,
>> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> maxMessageSize=0,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
>> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>> >> deliveryCount=0,
>> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
>> >> properties=null}
>> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
>> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>> >> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>> >> >>>> source=Source{address='null', durable=NONE,
>> expiryPolicy=LINK_DETACH,
>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
>> >> deliveryFailed=true,
>> >> >>>> undeliverableHere=null, messageAnnotations=null},
>> >> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list,
>> amqp:released:list,
>> >> >>>> amqp:modified:list], capabilities=[temporary-queue]},
>> >> >>>> target=Target{address='null', durable=NONE,
>> expiryPolicy=SESSION_END,
>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> capabilities=null},
>> >> >>>> unsettled=null, incompleteUnsettled=false,
>> initialDeliveryCount=null,
>> >> >>>> maxMessageSize=null, offeredCapabilities=null,
>> >> desiredCapabilities=null,
>> >> >>>> properties=null}
>> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
>> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>> >> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>> >> >>>> source=Source{address='null', durable=NONE,
>> expiryPolicy=SESSION_END,
>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>> >> outcomes=null,
>> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> maxMessageSize=0,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
>> >> >>>> error=Error{condition=qd:no-route-to-dest, description='No route
>> to
>> >> the
>> >> >>>> destination node', info=null}}
>> >> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
>> >> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
>> >> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
>> >> state=null,
>> >> >>>> resume=false, aborted=false, batchable=false} (312)
>> >> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
>> >> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
>> >> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$man
>> agement@
>> >> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
>> >> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
>> >> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
>> >> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
>> >> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
>> >> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
>> >> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
>> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>> >> deliveryCount=1,
>> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
>> >> properties=null}
>> >> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
>> >> >>>> settled=true, state=Accepted{}, batchable=false}
>> >> >>>> [1244186219:0] -> Close{error=null}
>> >> >>>> [1244186219:0] <- Close{error=null}
>> >> >>>>
>> >> >>>> Regards,
>> >> >>>>
>> >> >>>> Adel
>> >> >>>>
>> >> >>>> ________________________________
>> >> >>>> From: Robbie Gemmell <ro...@gmail.com>
>> >> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
>> >> >>>> To: users@qpid.apache.org
>> >> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>> >> >>>>
>> >> >>>> That looks fine at first glance. Its possible there is an issue in
>> >> >>>> there needing looked it. I am travelling this week so may not get
>> to
>> >> >>>> look until afterwards, but will try to give things a look at. If
>> you
>> >> >>>> could give more detail on the exception and maybe a protocol trace
>> >> >>>> that might be useful.
>> >> >>>>
>> >> >>>> Robbie
>> >> >>>>
>> >> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com>
>> wrote:
>> >> >>>>
>> >> >>>>> Hello Robbie,
>> >> >>>>>
>> >> >>>>> Thanks for you for your answer.
>> >> >>>>> I will try the solutions you proposed.
>> >> >>>>>
>> >> >>>>> I need just need one clarification. Concerning the Jms, I already
>> >> tried
>> >> >>>>> to
>> >> >>>>> use a temporary queue but it didn't work. May be i am using it
>> wrong.
>> >> >>>>> Here
>> >> >>>>> is what i did:
>> >> >>>>>
>> >> >>>>> ...
>> >> >>>>> Session session = connection.createSession(false,
>> >> >>>>> Session.AUTO_ACKNOWLEDGE);
>> >> >>>>> Queue queue = session.createQueue("$management");
>> >> >>>>> MessageProducer producer = session.createProducer(queue);
>> >> >>>>>
>> >> >>>>> Queue tempDest = session.createTemporaryQueue();
>> >> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDes
>> t);
>> >> >>>>> connection.start();
>> >> >>>>>
>> >> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
>> >> >>>>> objectMessage.setJMSReplyTo(tempDest);
>> >> >>>>> //fill the rest of the parameters ...
>> >> >>>>> producer.send(objectMessage);
>> >> >>>>> ObjectMessage replyMessage = (ObjectMessage)
>> >> >>>>> responseConsumer.receive(1000);
>> >> >>>>> ...
>> >> >>>>>
>> >> >>>>> I was getting an exception on the .receive() from the dispatch
>> router
>> >> >>>>> saying that the reply-to address is bad...
>> >> >>>>> Should i create the temporary queue and the consumer from a
>> different
>> >> >>>>> session then the producer?
>> >> >>>>>
>> >> >>>>> Best regards,
>> >> >>>>> Rabih
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
>> >> >>>>> robbie.gemmell@gmail.com>
>> >> >>>>> wrote:
>> >> >>>>>
>> >> >>>>> The session.createTemporaryQueue(); method is how JMS creates
>> >> >>>>>> temporary destinations for use in reply-to scenarios. The
>> dispatch
>> >> >>>>>> tools will be doing essentially the same thing under the covers
>> for
>> >> >>>>>> theirs.
>> >> >>>>>>
>> >> >>>>>> Both work by creating a 'dynamic' link attachment, with the
>> server
>> >> >>>>>> returning an address for the dynamic attach to the client. One
>> key
>> >> >>>>>> difference is with JMS you create the temporary destination (for
>> >> which
>> >> >>>>>> the client uses a dynamic sender link to create), then separately
>> >> >>>>>> create a receiver using it (and in turn the address associated
>> with
>> >> >>>>>> it), whereas non-JMS client/tools will typically just create a
>> >> single
>> >> >>>>>> dynamic receiver link and use its address for the reply-to.
>> >> >>>>>>
>> >> >>>>>> For proton-j, there aren't any examples for this, but you you
>> >> >>>>>> essentially would change the link opening to not specify an
>> address,
>> >> >>>>>> and instead set the source(for a receiver) or target (for a
>> sender)
>> >> to
>> >> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
>> >> remoteTarget
>> >> >>>>>> once the link had been reemotely attached, and get its
>> >> >>>>>> (server-generated) address, then use this as your reply-to.
>> >> >>>>>>
>> >> >>>>>> Robbie
>> >> >>>>>>
>> >> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
>> >> wrote:
>> >> >>>>>>
>> >> >>>>>>> Hello,
>> >> >>>>>>>
>> >> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like
>> you
>> >> >>>>>>> suggested, it worked.
>> >> >>>>>>> But I cheated a little to make it work because I did not find a
>> >> way in
>> >> >>>>>>>
>> >> >>>>>> JMS
>> >> >>>>>>
>> >> >>>>>>> to create a local queue. So I created a queue on the
>> qpid-dispatch
>> >> and
>> >> >>>>>>>
>> >> >>>>>> read
>> >> >>>>>>
>> >> >>>>>>> the result from it. You can check the attached code.
>> >> >>>>>>>
>> >> >>>>>>> Is there any way using qpid-jms to create a local queue on the
>> >> client
>> >> >>>>>>>
>> >> >>>>>> side
>> >> >>>>>>
>> >> >>>>>>> to serve as a reply to address?
>> >> >>>>>>>
>> >> >>>>>>> For the proton-j test, I have the same question as above. I saw
>> >> that
>> >> >>>>>>> it
>> >> >>>>>>>
>> >> >>>>>> can
>> >> >>>>>>
>> >> >>>>>>> be done with the C++ API. Are there any examples for proton-j or
>> >> >>>>>>>
>> >> >>>>>> something
>> >> >>>>>>
>> >> >>>>>>> that can help me?
>> >> >>>>>>>
>> >> >>>>>>> I saw may be in proton we don't need a local queue, may be we
>> can
>> >> get
>> >> >>>>>>> the
>> >> >>>>>>> address of the consumer directly and pass it in reply-to field.
>> Is
>> >> it
>> >> >>>>>>> correct?
>> >> >>>>>>>
>> >> >>>>>>> Thanks,
>> >> >>>>>>> Rabih
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
>> >> >>>>>>> rob.j.godfrey@gmail.com>
>> >> >>>>>>> wrote:
>> >> >>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gmurthy@redhat.com
>> >
>> >> >>>>>>>> wrote:
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>> ----- Original Message -----
>> >> >>>>>>>>>
>> >> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
>> >> >>>>>>>>>> To: users@qpid.apache.org
>> >> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
>> >> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid
>> >> Jms
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
>> >> wrote:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you
>> >> told
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>> me
>> >> >>>>>>
>> >> >>>>>>> Robbie and it worked.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> But like the proton-j case, the connector is not being
>> >> created on
>> >> >>>>>>>>>>>> the
>> >> >>>>>>>>>>>> Qpid-dispatch side.
>> >> >>>>>>>>>>>> I attached the amqp communication into this mail.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> The last frame in that file is incomplete (the previous
>> error
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> regarding the
>> >> >>>>>>>>>
>> >> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
>> >> frame
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> is
>> >> >>>>>>
>> >> >>>>>>> likely
>> >> >>>>>>>>>
>> >> >>>>>>>>>> the response which would indicate the success or otherwise of
>> >> the
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> frame. Is
>> >> >>>>>>>>>
>> >> >>>>>>>>>> there anything logged by the router?
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
>> >> simpler
>> >> >>>>>>>>>>> for
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> this
>> >> >>>>>>>>>
>> >> >>>>>>>>>> sort of thing in my view.
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more
>> helpful.
>> >> >>>>>>>>>> You
>> >> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
>> >> since
>> >> >>>>>>>>>> it
>> >> >>>>>>>>>> uses proton-j.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> One key difference from the qdmanage case is you are not
>> >> setting a
>> >> >>>>>>>>>> reply-to value or correlation-id to use along with it. I
>> don't
>> >> know
>> >> >>>>>>>>>>
>> >> >>>>>>>>> if
>> >> >>>>>>
>> >> >>>>>>> the router cares about not being able to send a response or not
>> >> >>>>>>>>>> though, but it might.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>> You could add the following to your dispatch router conf file
>> >> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable
>> trace
>> >> >>>>>>>>>
>> >> >>>>>>>> logging)
>> >> >>>>>>
>> >> >>>>>>>
>> >> >>>>>>>>> log {
>> >> >>>>>>>>> module: DEFAULT
>> >> >>>>>>>>> enable: trace+
>> >> >>>>>>>>> output: /path/to/log/qdrouterd.log
>> >> >>>>>>>>> }
>> >> >>>>>>>>>
>> >> >>>>>>>>> When you run your management request, you will see proton
>> frame
>> >> >>>>>>>>> trace
>> >> >>>>>>>>> and
>> >> >>>>>>>>> you will see additional logging out of the dispatch Python
>> agent
>> >> -
>> >> >>>>>>>>> something like the following -
>> >> >>>>>>>>>
>> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>> >> >>>>>>>>> Message(address=None,
>> >> >>>>>>>>> properties={'operation': 'CREATE', 'type':
>> >> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
>> >> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>> >> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
>> >> >>>>>>>>>
>> >> >>>>>>>> 'rabih.connector'},
>> >> >>>>>>
>> >> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>> >> >>>>>>>>> correlation_id=1L)
>> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>> >> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
>> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>> >> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True,
>> cost=1,
>> >> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
>> >> 5673:rabih.connector,
>> >> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>> >> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
>> >> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.
>> connector,
>> >> >>>>>>>>> verifyHostName=True)
>> >> >>>>>>>>>
>> >> >>>>>>>>> The Python management agent will not process your request if
>> >> there
>> >> >>>>>>>>> is
>> >> >>>>>>>>>
>> >> >>>>>>>> no
>> >> >>>>>>
>> >> >>>>>>> reply_to as seen here -
>> >> >>>>>>>>>
>> >> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
>> >> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
>> >> because
>> >> >>>>>>>> there
>> >> >>>>>>>> is
>> >> >>>>>>>> a reply-to doesn't mean that the sender will be around to
>> actually
>> >> >>>>>>>> hear
>> >> >>>>>>>> the
>> >> >>>>>>>> reply, so it seems a bit arbitrary to say that because we
>> *know*
>> >> the
>> >> >>>>>>>> sender
>> >> >>>>>>>> won't learn of the outcome that we won't do anything... The
>> spec
>> >> >>>>>>>> draft
>> >> >>>>>>>> doesn't currently say anything about this (obviously it should
>> >> do),
>> >> >>>>>>>> but
>> >> >>>>>>>>
>> >> >>>>>>> my
>> >> >>>>>>
>> >> >>>>>>> expectation would certainly be that a request would be processed
>> >> even
>> >> >>>>>>>> if
>> >> >>>>>>>> the replyTo address was not present (or ended up not routing
>> >> >>>>>>>> anywhere).
>> >> >>>>>>>> This is also how the Qpid Broker for Java implements this case.
>> >> >>>>>>>>
>> >> >>>>>>>> -- Rob
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>> Thanks.
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>>> Robbie
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> ------------------------------------------------------------
>> >> >>>>>>>>>>
>> >> >>>>>>>>> ---------
>> >> >>>>>>
>> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>> ------------------------------------------------------------
>> >> >>>>>>>>> ---------
>> >> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> ------------------------------------------------------------
>> >> ---------
>> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>>>>>>
>> >> >>>>>>
>> >> >>>>>> ------------------------------------------------------------
>> >> ---------
>> >> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>> ------------------------------------------------------------
>> ---------
>> >> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>>>
>> >> >>>>
>> >> >>> ------------------------------------------------------------
>> ---------
>> >> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>>
>> >> >>>
>> >> >> ------------------------------------------------------------
>> ---------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> For additional commands, e-mail: users-help@qpid.apache.org
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Robbie Gemmell <ro...@gmail.com>.
I tried this (modified to use a temporary queue) and also modified the
Qpid JMS HelloWorld example to use a temporary queue, and ran both
against the router successfully multiple times, using the jms client
from master, dispatch from master, and proton from master.
The only odd thing was that Dispatch printed out two copies of notices
about the connection closing without the links being explicitly
detached, which is what the examples do and not something I would
consider unusual. I wouldnt really expect to see these notices, but if
so then only one copy.
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
due to parent connection end
As an aside, the typical TemporaryQueue usage would be just to use the
destination object directly, i.e the below, not ask its name and
create another destination with that name. I tried both ways just to
check it wasnt related though and they both worked the same.
TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
managementConsumer = managementSession.createConsumer(temporaryQueue);
On 22 February 2017 at 11:33, Adel Boutros <Ad...@live.com> wrote:
> Hello guys,
>
>
> My basic JMS API is almost ready. I will share it with you soon to have your feedback.
>
>
> However, I tried one last thing by getting a random queue name and using it as management reply queue to allow multiple configuration sessions simultaneously but it didn't work.
>
>
> //This doesn't work and crashes the dispatch router
>
> TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
> replyToQueue = managementSession.createQueue(temporaryQueue.getQueueName());
> managementConsumer = managementSession.createConsumer(replyToQueue);
>
> //This is the only thing working
> replyToQueue = managementSession.createQueue("HARD_CODED_REPLY_QUEUE");
> managementConsumer = managementSession.createConsumer(replyToQueue);
>
>
> Can I have your input on the above?
>
> Regards,
> Adel
>
>
> ________________________________
> From: Rob Godfrey <ro...@gmail.com>
> Sent: Wednesday, February 15, 2017 4:46:59 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> On 15 February 2017 at 16:07, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> On 15 February 2017 at 14:15, Adel Boutros <Ad...@live.com> wrote:
>> > Hello guys,
>> >
>> >
>> > Based on the discussion, we are currently writing a Java API based on
>> JMS to configure the dispatch router. I have so far managed to do the
>> following:
>> >
>> > * Create, Read, Delete addresses
>> >
>> > * Create, Read, Delete connectors
>> >
>> >
>> > Config:
>> >
>> > Dispatch Router 0.7.0
>> >
>> > JMS 0.11.1
>> >
>> >
>> > And I have noticed some problems and differences:
>> >
>> >
>> > 1) It seems some calls return ObjectMessage and some TextMessage (This
>> is on the side of the consumer in the replyTo)
>> >
>> > For example, creating twice the same queue will fail but the second call
>> will return a JmsTextMessage with an empty body and status code 400
>> >
>>
>> The client treats messages with an amqp-value sectioning containing
>> null/nothing as a TextMessage with null value if they arent annotated
>> to say otherwise, I'd guess thats where that comes from.
>>
>> >
>> > 2) Returned statusCode differs between Connector and Address
>> >
>> > Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
>> >
>> >
>> > * Connector operations return java.lang.Long
>> > * Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
>> >
>>
>> The router is presumably sending different values back for the
>> different operations here, a long and a uint. The router should
>> perhaps be consistent, and the client should perhaps not be returning
>> the uint object either way.
>>
>> The last draft of the management spec seems to say the status code
>> should be 'integer', im not clear if it means int (not uint)
>> specifically, or just any integral type value.
>>
>>
> The specification should definitely say which type should - so we'll fix
> that in the next draft. I'd suggest we should int (in AMQP terms) leading
> to a java.lang.Integer type in the property you see through Java.
>
> -- Rob
>
>
>
>> >
>> > 3) Create connector twice makes dispatch router crash. I don't have the
>> issue when creating addresses.
>> > On the second create call, JMS client receives a normal reply
>> containing a statusCode of an exception. After I close the connection to
>> the dispatch router via JMS (connection.close), I have the below crash
>> >
>> > (gdb) where
>> > #0 0x00007f27194448a5 in raise () from /lib64/libc.so.6
>> > #1 0x00007f2719446085 in abort () from /lib64/libc.so.6
>> > #2 0x00007f27194827b7 in __libc_message () from /lib64/libc.so.6
>> > #3 0x00007f27194880e6 in malloc_printerr () from /lib64/libc.so.6
>> > #4 0x00007f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf
>> expression opcode 0xf3
>> > ) at /qpid-dispatch-0.7.0/src/hash.c:320
>> > #5 0x00007f271a42247d in qdr_route_check_id_for_deletion_CT
>> (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
>> > ) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
>> > #6 0x00007f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30,
>> action=Unhandled dwarf expression opcode 0xf3
>> > ) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
>> > #7 0x00007f271a423f30 in router_core_thread (arg=0x13d2d30) at
>> /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
>> > #8 0x00007f2719f8c851 in start_thread () from /lib64/libpthread.so.0
>> > #9 0x00007f27194fa90d in clone () from /lib64/libc.so.6
>> >
>> >
>> > Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE:
>> org.apache.qpid.dispatch.connector: Duplicate value 'connector/
>> 127.0.0.1:5915:dispatch_management_connector_test' for unique attribute
>> 'identity'
>> > *** glibc detected *** /Dispatch/sbin/qdrouterd: double free or
>> corruption (fasttop): 0x00007f2708033f10 ***
>> > ======= Backtrace: =========
>> > /lib64/libc.so.6(+0x760e6)[0x7f27194880e6]
>> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>> .so(qd_hash_remove_by_handle+0x29)[0x7f271a40f109]
>> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>> .so(+0x3547d)[0x7f271a42247d]
>> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>> .so(+0x318d3)[0x7f271a41e8d3]
>> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
>> .so(router_core_thread+0x230)[0x7f271a423f30]
>> > /lib64/libpthread.so.0(+0x7851)[0x7f2719f8c851]
>> > /lib64/libc.so.6(clone+0x6d)[0x7f27194fa90d]
>> > ======= Memory map: ========
>> > 00400000-00403000 r-xp 00000000 fd:01 7735642
>> /Dispatch/sbin/qdrouterd
>> > 00603000-00604000 rw-p 00003000 fd:01 7735642
>> /Dispatch/sbin/qdrouterd
>> > 01113000-01458000 rw-p 00000000 00:00 0
>> [heap]
>> > 7f26f8000000-7f26f805c000 rw-p 00000000 00:00 0
>> > 7f26f805c000-7f26fc000000 ---p 00000000 00:00 0
>> > 7f26fc000000-7f26fc043000 rw-p 00000000 00:00 0
>> > 7f26fc043000-7f2700000000 ---p 00000000 00:00 0
>> > 7f2700000000-7f2700085000 rw-p 00000000 00:00 0
>> > 7f2700085000-7f2704000000 ---p 00000000 00:00 0
>> > 7f27073e9000-7f27073ff000 r-xp 00000000 fd:00 524293
>> /lib64/libgcc_s-4.4.7-20120601.so.1
>> > 7f27073ff000-7f27075fe000 ---p 00016000 fd:00 524293
>> /lib64/libgcc_s-4.4.7-20120601.so.1
>> > 7f27075fe000-7f27075ff000 rw-p 00015000 fd:00 524293
>> /lib64/libgcc_s-4.4.7-20120601.so.1
>> > 7f27075ff000-7f2707600000 ---p 00000000 00:00 0
>> > 7f2707600000-7f2708000000 rw-p 00000000 00:00 0
>> > 7f2708000000-7f270805a000 rw-p 00000000 00:00 0
>> > 7f270805a000-7f270c000000 ---p 00000000 00:00 0
>> > 7f270c04a000-7f270c04f000 r-xp 00000000 fd:00 524322
>> /lib64/libnss_dns-2.12.so
>> > 7f270c04f000-7f270c24e000 ---p 00005000 fd:00 524322
>> /lib64/libnss_dns-2.12.so
>> > 7f270c24e000-7f270c24f000 r--p 00004000 fd:00 524322
>> /lib64/libnss_dns-2.12.so
>> > 7f270c24f000-7f270c250000 rw-p 00005000 fd:00 524322
>> /lib64/libnss_dns-2.12.so
>> > 7f270c250000-7f270c251000 ---p 00000000 00:00 0
>> > 7f270c251000-7f270cc51000 rw-p 00000000 00:00 0
>> > 7f270cc51000-7f270cc52000 ---p 00000000 00:00 0
>> > 7f270cc52000-7f270d652000 rw-p 00000000 00:00 0
>> > 7f270d652000-7f270d65e000 r-xp 00000000 fd:00 524324
>> /lib64/libnss_files-2.12.so
>> > 7f270d65e000-7f270d85e000 ---p 0000c000 fd:00 524324
>> /lib64/libnss_files-2.12.so
>> > 7f270d85e000-7f270d85f000 r--p 0000c000 fd:00 524324
>> /lib64/libnss_files-2.12.so
>> > 7f270d85f000-7f270d860000 rw-p 0000d000 fd:00 524324
>> /lib64/libnss_files-2.12.so
>> > 7f270d86a000-7f270d86b000 ---p 00000000 00:00 0
>> > 7f270d86b000-7f270e3ac000 rw-p 00000000 00:00 0
>> > 7f270e3ac000-7f270e3b1000 r-xp 00000000 00:16 4090944
>> /python278/lib/python2.7/lib-dynload/select.so
>> > 7f270e3b1000-7f270e5b0000 ---p 00005000 00:16 4090944
>> /python278/lib/python2.7/lib-dynload/select.so
>> > 7f270e5b0000-7f270e5b2000 rw-p 00004000 00:16 4090944
>> /python278/lib/python2.7/lib-dynload/select.so
>> > 7f270e5b2000-7f270e5b6000 r-xp 00000000 00:16 5568743
>> /python278/lib/python2.7/lib-dynload/_lsprof.so
>> > 7f270e5b6000-7f270e7b5000 ---p 00004000 00:16 5568743
>> /python278/lib/python2.7/lib-dynload/_lsprof.so
>> > 7f270e7b5000-7f270e7b6000 rw-p 00003000 00:16 5568743
>> /python278/lib/python2.7/lib-dynload/_lsprof.so
>> > 7f270e7b6000-7f270e8b7000 rw-p 00000000 00:00 0
>> > 7f270e8b7000-7f270e8bc000 r-xp 00000000 00:16 6394000
>> /python278/lib/python2.7/lib-dynload/strop.so
>> > 7f270e8bc000-7f270eabb000 ---p 00005000 00:16 6394000
>> /python278/lib/python2.7/lib-dynload/strop.so
>> > 7f270eabb000-7f270eabd000 rw-p 00004000 00:16 6394000
>> /python278/lib/python2.7/lib-dynload/strop.so
>> > 7f270eabd000-7f270eafd000 rw-p 00000000 00:00 0
>> > 7f270eafd000-7f270eb00000 r-xp 00000000 00:16 5568749
>> /python278/lib/python2.7/lib-dynload/fcntl.so
>> > 7f270eb00000-7f270ecff000 ---p 00003000 00:16 5568749
>> /python278/lib/python2.7/lib-dynload/fcntl.so
>> > 7f270ecff000-7f270ed01000 rw-p 00002000 00:16 5568749
>> /python278/lib/python2.7/lib-dynload/fcntl.so
>> > 7f270ed01000-7f270ed04000 r-xp 00000000 00:16 5568739
>> /python278/lib/python2.7/lib-dynload/_random.so
>> > 7f270ed04000-7f270ef03000 ---p 00003000 00:16 5568739
>> /python278/lib/python2.7/lib-dynload/_random.so
>> > 7f270ef03000-7f270ef04000 rw-p 00002000 00:16 5568739
>> /python278/lib/python2.7/lib-dynload/_random.so
>> > 4272 Aborted (core dumped)
>> >
>> >
>> > Regards,
>> > Adel
>> >
>> >
>> > ________________________________
>> > From: Rob Godfrey <ro...@gmail.com>
>> > Sent: Monday, February 6, 2017 7:09 PM
>> > To: users@qpid.apache.org
>> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>> >
>> > On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
>> > wrote:
>> >
>> >> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com>
>> wrote:
>> >> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
>> >> >
>> >> >> It seems odd that the client creates a _sender_ to the temporary
>> queue
>> >> >> that it will never send messages _to_ but will receive messages
>> _from_.
>> >> >>
>> >> >>
>> >> > This is because JMS semantics require the temporary node to have a
>> >> lifetime
>> >> > scoped to the session (not a link), so the JMS client has to create a
>> >> > synthetic link which it uses simply to manage the lifetime of the
>> dynamic
>> >> > node. In order to not cause unintentional assigning of messages to a
>> >> link
>> >> > that will never actually be used for consumption, a sending link is
>> used.
>> >> > Note that in general JMS would expect that you should be able to send
>> to
>> >> a
>> >> > temporary queue created in this way (since the point of temporary
>> queues
>> >> is
>> >> > to use as a reply to)
>> >> >
>> >>
>> >> Not really important here, but the lifetime is scoped to the
>> >> Connection, not Session (agghhh JMS... :P)
>> >>
>> >
>> > That's what I thought I was typing... obviously my fingers were not
>> > cooperating with my brain at that point :-)
>> >
>> > -- Rob
>> >
>> >
>> >>
>> >> >
>> >> >> Anyway, when the client creates a receiver with a dynamic source
>> (and no
>> >> >> dynamic-node-properties), the router will accept the link and assign
>> a
>> >> >> temporary address as the source. This is only useful in this use
>> case
>> >> if
>> >> >> the broker has a way of knowing that the temporary address is
>> reachable
>> >> via
>> >> >> the router network.
>> >> >>
>> >> >> There is a way to route dynamic termini to a broker. If an
>> >> >> x-opt-qd.address property is included in the dynamic-node-properties,
>> >> this
>> >> >> address will be used to route the attach to the broker. I've never
>> >> tested
>> >> >> this with a dynamic target in a sender. It might not work.
>> >> >
>> >> >
>> >> > And this really isn't something you'd be expecting a generic client
>> (like
>> >> > the JMS client) to know :-)
>> >> >
>> >> > -- Rob
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> -Ted
>> >> >>
>> >> >>
>> >> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
>> >> >>
>> >> >>> I've had a look at this. It would seem that Dispatch doesn't like
>> what
>> >> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
>> >> >>> very nice way, and the client then doesnt notice that things have
>> gone
>> >> >>> south in a somewhat unexpected way.
>> >> >>>
>> >> >>> The client opens a sending link with 'dynamic' target in order to
>> >> >>> create a dynamic node for use as a TemporaryQueue
>> address/destination
>> >> >>> object, which specific consumers/producers are then created against
>> by
>> >> >>> the application. Dispatch doesn't seem to like that but erroneously
>> >> >>> attaches the link 'successfully', though doesnt set a target address
>> >> >>> as is expected. The client then doesnt notice this happened (its
>> >> >>> checking for the link being refused, which it wasn't), allowing the
>> >> >>> application to proceed as far as creating consumers/procuers using
>> the
>> >> >>> TemporaryQueue object, with creation of the e.g Consumer then
>> failing
>> >> >>> since the attach doesnt contain the needed information and leads to
>> >> >>> Dispatch detaching it with the error (though it again doesnt
>> actually
>> >> >>> indicate its refusing the link during the attach response, as it
>> >> >>> probably should have in this case).
>> >> >>>
>> >> >>> Making the client detect the current failure and having it throw an
>> >> >>> aexception from createTemporaryQueue is simple enough.
>> >> >>>
>> >> >>> Hacking the client to use a dynamic recieving link instead, an
>> address
>> >> >>> was returned by Dispatch in the attach response as expected,
>> however a
>> >> >>> consumer on the resulting TemporaryQueue object using this address
>> >> >>> still didnt get the message I sent to the same place. If I also gave
>> >> >>> some credit on the link backing the TemporaryQeueue object itself
>> then
>> >> >>> that link gets sent the message by Dispatch, though this of no use
>> for
>> >> >>> the JMS client.
>> >> >>>
>> >> >>> Needs some more investigation, and I'll need to discuss with some
>> >> >>> folks more familiar with Dispatch.
>> >> >>>
>> >> >>> Robbie
>> >> >>>
>> >> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
>> >> wrote:
>> >> >>>
>> >> >>>> Hello Robbie,
>> >> >>>>
>> >> >>>>
>> >> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the
>> reply
>> >> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS
>> Client.
>> >> >>>>
>> >> >>>>
>> >> >>>> PS: As Rabih stated before, we are using the same connection and
>> same
>> >> >>>> session to create the JMSProducer for the request and the
>> >> JMSConsumer for
>> >> >>>> the reply.
>> >> >>>>
>> >> >>>>
>> >> >>>> Exception
>> >> >>>> -------------------
>> >> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed
>> due
>> >> to
>> >> >>>> an unrecoverable error.
>> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
>> >> >>>> eConsumer.java:330)
>> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
>> >> >>>> sumer.java:196)
>> >> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
>> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> >> >>>> ssorImpl.java:62)
>> >> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> >> >>>> thodAccessorImpl.java:43)
>> >> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
>> >> >>>> at com.intellij.rt.execution.application.AppMain.main(
>> >> AppMain.java:147)
>> >> >>>> Caused by: javax.jms.JMSException: No route to the destination node
>> >> >>>> [condition = qd:no-route-to-dest]
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>> >> >>>> tion(AmqpSupport.java:150)
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>> >> >>>> tion(AmqpSupport.java:105)
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
>> >> >>>> elyClosed(AmqpAbstractResource.java:147)
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
>> >> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
>> >> >>>> s(AmqpProvider.java:795)
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
>> >> >>>> mqpProvider.java:90)
>> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
>> >> >>>> ovider.java:699)
>> >> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
>> >> >>>> Executors.java:511)
>> >> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>> >> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>> >> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
>> >> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> >> >>>> Executor.java:1142)
>> >> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> >> >>>> lExecutor.java:617)
>> >> >>>> at java.lang.Thread.run(Thread.java:745)
>> >> >>>>
>> >> >>>>
>> >> >>>> -------------------
>> >> >>>> Dispatch Router (PN_TRACE_FRM=1)
>> >> >>>> -------------------
>> >> >>>>
>> >> >>>> [832220]: <- SASL
>> >> >>>> [832220]: -> SASL
>> >> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
>> >> >>>> MBOL[:ANONYMOUS]]
>> >> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
>> >> >>>> initial-response=b"", hostname="host-name"]
>> >> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
>> >> >>>> [832220]: <- AMQP
>> >> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
>> >> a334-44c3-954a-2dd910161411:1",
>> >> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
>> >> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
>> >> >>>> L[:"sole-connection-for-container"],
>> properties={:product="QpidJMS",
>> >> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
>> >> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
>> >> >>>> [832220]: -> AMQP
>> >> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
>> >> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
>> >> >>>> offered-capabilities=:"ANONYMOUS-RELAY",
>> properties={:product="qpid-
>> >> dispatch-router",
>> >> >>>> :version="0.7.0"}]
>> >> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>> >> >>>> outgoing-window=2147483647, handle-max=65535]
>> >> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
>> >> >>>> incoming-window=61, outgoing-window=2147483647]
>> >> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>> >> >>>> outgoing-window=2147483647, handle-max=65535]
>> >> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
>> >> >>>> incoming-window=61, outgoing-window=2147483647]
>> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
>> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
>> source=@source(40)
>> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
>> durable=0,
>> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list",
>> :"amqp:rejected:list"]],
>> >> >>>> target=@target(41) [address="$management", durable=0,
>> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>> >> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
>> >> >>>> initial-delivery-count=0]
>> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
>> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>> >> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
>> durable=0,
>> >> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:acc
>> epted:list",
>> >> >>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
>> >> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
>> >> queue]],
>> >> >>>> initial-delivery-count=0, max-message-size=0]
>> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>> >> delivery-count=0,
>> >> >>>> link-credit=250, drain=false]
>> >> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
>> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
>> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
>> source=@source(40)
>> >> [],
>> >> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
>> >> timeout=0,
>> >> >>>> dynamic=true, dynamic-node-properties={:"lif
>> >> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
>> >> temporary-queue"]],
>> >> >>>> incomplete-unsettled=false, initial-delivery-count=0]
>> >> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
>> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
>> >> role=true,
>> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>> [durable=0,
>> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
>> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
>> >> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43)
>> []},
>> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
>> >> initial-delivery-count=0,
>> >> >>>> max-message-size=0]
>> >> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>> >> delivery-count=0,
>> >> >>>> link-credit=250, drain=false]
>> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
>> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
>> role=true,
>> >> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
>> [durable=0,
>> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
>> >> >>>> default-outcome=@modified(39) [delivery-failed=true],
>> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
>> >> >>>> :"amqp:released:list", :"amqp:modified:list"],
>> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41)
>> []]
>> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
>> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
>> role=false,
>> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>> [durable=0,
>> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
>> timeout=0,
>> >> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
>> >> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
>> >> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
>> >> >>>> destination node"]]
>> >> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
>> >> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
>> >> delivery-tag=b"0",
>> >> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
>> >> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
>> >> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
>> >> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
>> >> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
>> >> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
>> >> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
>> >> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
>> >> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
>> >> >>>> x04addr\xa1\x0dbrokerMachine"
>> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
>> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>> >> delivery-count=1,
>> >> >>>> link-credit=250, drain=false]
>> >> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
>> >> >>>> settled=true, state=@accepted(36) []]
>> >> >>>> [832220]:0 <- @close(24) []
>> >> >>>> [832220]: <- EOS
>> >> >>>> [832220]:0 -> @close(24) []
>> >> >>>> [832220]: -> EOS
>> >> >>>> Closed x.x.x.x:8961
>> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
>> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
>> >> >>>>
>> >> >>>> ------------------
>> >> >>>> JMS Client (PN_TRACE_FRM=1)
>> >> >>>> ------------------
>> >> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
>> >> 4a22-9b22-69d27a017a83:1',
>> >> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
>> >> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
>> >> connection-for-container],
>> >> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM:
>> 1.8.0_111,
>> >> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
>> >> >>>> [1244186219:0] <- Open{ containerId='router.10200',
>> hostname='null',
>> >> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
>> >> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
>> >> ANONYMOUS-RELAY],
>> >> >>>> desiredCapabilities=null, properties={product=qpid-dispa
>> tch-router,
>> >> >>>> version=0.7.0}}
>> >> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
>> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
>> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
>> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
>> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
>> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
>> handle=0,
>> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
>> >> 3293ffc57168:1:1:1',
>> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
>> >> amqp:rejected:list],
>> >> >>>> capabilities=null}, target=Target{address='$management',
>> >> durable=NONE,
>> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> >> maxMessageSize=null,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
>> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
>> handle=0,
>> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
>> >> 3293ffc57168:1:1:1',
>> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
>> >> amqp:rejected:list],
>> >> >>>> capabilities=null}, target=Target{address='$management',
>> >> durable=NONE,
>> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> maxMessageSize=0,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
>> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>> >> deliveryCount=0,
>> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
>> >> properties=null}
>> >> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
>> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>> >> >>>> source=Source{address='null', durable=NONE,
>> expiryPolicy=SESSION_END,
>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>> >> outcomes=null,
>> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> >> maxMessageSize=null,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
>> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>> >> >>>> source=Source{address='null', durable=NONE,
>> expiryPolicy=SESSION_END,
>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>> >> outcomes=null,
>> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> maxMessageSize=0,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
>> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>> >> deliveryCount=0,
>> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
>> >> properties=null}
>> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
>> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>> >> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>> >> >>>> source=Source{address='null', durable=NONE,
>> expiryPolicy=LINK_DETACH,
>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
>> >> deliveryFailed=true,
>> >> >>>> undeliverableHere=null, messageAnnotations=null},
>> >> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list,
>> amqp:released:list,
>> >> >>>> amqp:modified:list], capabilities=[temporary-queue]},
>> >> >>>> target=Target{address='null', durable=NONE,
>> expiryPolicy=SESSION_END,
>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> capabilities=null},
>> >> >>>> unsettled=null, incompleteUnsettled=false,
>> initialDeliveryCount=null,
>> >> >>>> maxMessageSize=null, offeredCapabilities=null,
>> >> desiredCapabilities=null,
>> >> >>>> properties=null}
>> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
>> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>> >> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>> >> >>>> source=Source{address='null', durable=NONE,
>> expiryPolicy=SESSION_END,
>> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>> >> outcomes=null,
>> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
>> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> maxMessageSize=0,
>> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
>> properties=null}
>> >> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
>> >> >>>> error=Error{condition=qd:no-route-to-dest, description='No route
>> to
>> >> the
>> >> >>>> destination node', info=null}}
>> >> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
>> >> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
>> >> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
>> >> state=null,
>> >> >>>> resume=false, aborted=false, batchable=false} (312)
>> >> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
>> >> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
>> >> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$man
>> agement@
>> >> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
>> >> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
>> >> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
>> >> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
>> >> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
>> >> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
>> >> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
>> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>> >> deliveryCount=1,
>> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
>> >> properties=null}
>> >> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
>> >> >>>> settled=true, state=Accepted{}, batchable=false}
>> >> >>>> [1244186219:0] -> Close{error=null}
>> >> >>>> [1244186219:0] <- Close{error=null}
>> >> >>>>
>> >> >>>> Regards,
>> >> >>>>
>> >> >>>> Adel
>> >> >>>>
>> >> >>>> ________________________________
>> >> >>>> From: Robbie Gemmell <ro...@gmail.com>
>> >> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
>> >> >>>> To: users@qpid.apache.org
>> >> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>> >> >>>>
>> >> >>>> That looks fine at first glance. Its possible there is an issue in
>> >> >>>> there needing looked it. I am travelling this week so may not get
>> to
>> >> >>>> look until afterwards, but will try to give things a look at. If
>> you
>> >> >>>> could give more detail on the exception and maybe a protocol trace
>> >> >>>> that might be useful.
>> >> >>>>
>> >> >>>> Robbie
>> >> >>>>
>> >> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com>
>> wrote:
>> >> >>>>
>> >> >>>>> Hello Robbie,
>> >> >>>>>
>> >> >>>>> Thanks for you for your answer.
>> >> >>>>> I will try the solutions you proposed.
>> >> >>>>>
>> >> >>>>> I need just need one clarification. Concerning the Jms, I already
>> >> tried
>> >> >>>>> to
>> >> >>>>> use a temporary queue but it didn't work. May be i am using it
>> wrong.
>> >> >>>>> Here
>> >> >>>>> is what i did:
>> >> >>>>>
>> >> >>>>> ...
>> >> >>>>> Session session = connection.createSession(false,
>> >> >>>>> Session.AUTO_ACKNOWLEDGE);
>> >> >>>>> Queue queue = session.createQueue("$management");
>> >> >>>>> MessageProducer producer = session.createProducer(queue);
>> >> >>>>>
>> >> >>>>> Queue tempDest = session.createTemporaryQueue();
>> >> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDes
>> t);
>> >> >>>>> connection.start();
>> >> >>>>>
>> >> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
>> >> >>>>> objectMessage.setJMSReplyTo(tempDest);
>> >> >>>>> //fill the rest of the parameters ...
>> >> >>>>> producer.send(objectMessage);
>> >> >>>>> ObjectMessage replyMessage = (ObjectMessage)
>> >> >>>>> responseConsumer.receive(1000);
>> >> >>>>> ...
>> >> >>>>>
>> >> >>>>> I was getting an exception on the .receive() from the dispatch
>> router
>> >> >>>>> saying that the reply-to address is bad...
>> >> >>>>> Should i create the temporary queue and the consumer from a
>> different
>> >> >>>>> session then the producer?
>> >> >>>>>
>> >> >>>>> Best regards,
>> >> >>>>> Rabih
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
>> >> >>>>> robbie.gemmell@gmail.com>
>> >> >>>>> wrote:
>> >> >>>>>
>> >> >>>>> The session.createTemporaryQueue(); method is how JMS creates
>> >> >>>>>> temporary destinations for use in reply-to scenarios. The
>> dispatch
>> >> >>>>>> tools will be doing essentially the same thing under the covers
>> for
>> >> >>>>>> theirs.
>> >> >>>>>>
>> >> >>>>>> Both work by creating a 'dynamic' link attachment, with the
>> server
>> >> >>>>>> returning an address for the dynamic attach to the client. One
>> key
>> >> >>>>>> difference is with JMS you create the temporary destination (for
>> >> which
>> >> >>>>>> the client uses a dynamic sender link to create), then separately
>> >> >>>>>> create a receiver using it (and in turn the address associated
>> with
>> >> >>>>>> it), whereas non-JMS client/tools will typically just create a
>> >> single
>> >> >>>>>> dynamic receiver link and use its address for the reply-to.
>> >> >>>>>>
>> >> >>>>>> For proton-j, there aren't any examples for this, but you you
>> >> >>>>>> essentially would change the link opening to not specify an
>> address,
>> >> >>>>>> and instead set the source(for a receiver) or target (for a
>> sender)
>> >> to
>> >> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
>> >> remoteTarget
>> >> >>>>>> once the link had been reemotely attached, and get its
>> >> >>>>>> (server-generated) address, then use this as your reply-to.
>> >> >>>>>>
>> >> >>>>>> Robbie
>> >> >>>>>>
>> >> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
>> >> wrote:
>> >> >>>>>>
>> >> >>>>>>> Hello,
>> >> >>>>>>>
>> >> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like
>> you
>> >> >>>>>>> suggested, it worked.
>> >> >>>>>>> But I cheated a little to make it work because I did not find a
>> >> way in
>> >> >>>>>>>
>> >> >>>>>> JMS
>> >> >>>>>>
>> >> >>>>>>> to create a local queue. So I created a queue on the
>> qpid-dispatch
>> >> and
>> >> >>>>>>>
>> >> >>>>>> read
>> >> >>>>>>
>> >> >>>>>>> the result from it. You can check the attached code.
>> >> >>>>>>>
>> >> >>>>>>> Is there any way using qpid-jms to create a local queue on the
>> >> client
>> >> >>>>>>>
>> >> >>>>>> side
>> >> >>>>>>
>> >> >>>>>>> to serve as a reply to address?
>> >> >>>>>>>
>> >> >>>>>>> For the proton-j test, I have the same question as above. I saw
>> >> that
>> >> >>>>>>> it
>> >> >>>>>>>
>> >> >>>>>> can
>> >> >>>>>>
>> >> >>>>>>> be done with the C++ API. Are there any examples for proton-j or
>> >> >>>>>>>
>> >> >>>>>> something
>> >> >>>>>>
>> >> >>>>>>> that can help me?
>> >> >>>>>>>
>> >> >>>>>>> I saw may be in proton we don't need a local queue, may be we
>> can
>> >> get
>> >> >>>>>>> the
>> >> >>>>>>> address of the consumer directly and pass it in reply-to field.
>> Is
>> >> it
>> >> >>>>>>> correct?
>> >> >>>>>>>
>> >> >>>>>>> Thanks,
>> >> >>>>>>> Rabih
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
>> >> >>>>>>> rob.j.godfrey@gmail.com>
>> >> >>>>>>> wrote:
>> >> >>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gmurthy@redhat.com
>> >
>> >> >>>>>>>> wrote:
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>> ----- Original Message -----
>> >> >>>>>>>>>
>> >> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
>> >> >>>>>>>>>> To: users@qpid.apache.org
>> >> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
>> >> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid
>> >> Jms
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
>> >> wrote:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you
>> >> told
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>> me
>> >> >>>>>>
>> >> >>>>>>> Robbie and it worked.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> But like the proton-j case, the connector is not being
>> >> created on
>> >> >>>>>>>>>>>> the
>> >> >>>>>>>>>>>> Qpid-dispatch side.
>> >> >>>>>>>>>>>> I attached the amqp communication into this mail.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> The last frame in that file is incomplete (the previous
>> error
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> regarding the
>> >> >>>>>>>>>
>> >> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
>> >> frame
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> is
>> >> >>>>>>
>> >> >>>>>>> likely
>> >> >>>>>>>>>
>> >> >>>>>>>>>> the response which would indicate the success or otherwise of
>> >> the
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> frame. Is
>> >> >>>>>>>>>
>> >> >>>>>>>>>> there anything logged by the router?
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
>> >> simpler
>> >> >>>>>>>>>>> for
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> this
>> >> >>>>>>>>>
>> >> >>>>>>>>>> sort of thing in my view.
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more
>> helpful.
>> >> >>>>>>>>>> You
>> >> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
>> >> since
>> >> >>>>>>>>>> it
>> >> >>>>>>>>>> uses proton-j.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> One key difference from the qdmanage case is you are not
>> >> setting a
>> >> >>>>>>>>>> reply-to value or correlation-id to use along with it. I
>> don't
>> >> know
>> >> >>>>>>>>>>
>> >> >>>>>>>>> if
>> >> >>>>>>
>> >> >>>>>>> the router cares about not being able to send a response or not
>> >> >>>>>>>>>> though, but it might.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>> You could add the following to your dispatch router conf file
>> >> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable
>> trace
>> >> >>>>>>>>>
>> >> >>>>>>>> logging)
>> >> >>>>>>
>> >> >>>>>>>
>> >> >>>>>>>>> log {
>> >> >>>>>>>>> module: DEFAULT
>> >> >>>>>>>>> enable: trace+
>> >> >>>>>>>>> output: /path/to/log/qdrouterd.log
>> >> >>>>>>>>> }
>> >> >>>>>>>>>
>> >> >>>>>>>>> When you run your management request, you will see proton
>> frame
>> >> >>>>>>>>> trace
>> >> >>>>>>>>> and
>> >> >>>>>>>>> you will see additional logging out of the dispatch Python
>> agent
>> >> -
>> >> >>>>>>>>> something like the following -
>> >> >>>>>>>>>
>> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>> >> >>>>>>>>> Message(address=None,
>> >> >>>>>>>>> properties={'operation': 'CREATE', 'type':
>> >> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
>> >> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>> >> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
>> >> >>>>>>>>>
>> >> >>>>>>>> 'rabih.connector'},
>> >> >>>>>>
>> >> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>> >> >>>>>>>>> correlation_id=1L)
>> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>> >> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
>> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>> >> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True,
>> cost=1,
>> >> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
>> >> 5673:rabih.connector,
>> >> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>> >> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
>> >> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.
>> connector,
>> >> >>>>>>>>> verifyHostName=True)
>> >> >>>>>>>>>
>> >> >>>>>>>>> The Python management agent will not process your request if
>> >> there
>> >> >>>>>>>>> is
>> >> >>>>>>>>>
>> >> >>>>>>>> no
>> >> >>>>>>
>> >> >>>>>>> reply_to as seen here -
>> >> >>>>>>>>>
>> >> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
>> >> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
>> >> because
>> >> >>>>>>>> there
>> >> >>>>>>>> is
>> >> >>>>>>>> a reply-to doesn't mean that the sender will be around to
>> actually
>> >> >>>>>>>> hear
>> >> >>>>>>>> the
>> >> >>>>>>>> reply, so it seems a bit arbitrary to say that because we
>> *know*
>> >> the
>> >> >>>>>>>> sender
>> >> >>>>>>>> won't learn of the outcome that we won't do anything... The
>> spec
>> >> >>>>>>>> draft
>> >> >>>>>>>> doesn't currently say anything about this (obviously it should
>> >> do),
>> >> >>>>>>>> but
>> >> >>>>>>>>
>> >> >>>>>>> my
>> >> >>>>>>
>> >> >>>>>>> expectation would certainly be that a request would be processed
>> >> even
>> >> >>>>>>>> if
>> >> >>>>>>>> the replyTo address was not present (or ended up not routing
>> >> >>>>>>>> anywhere).
>> >> >>>>>>>> This is also how the Qpid Broker for Java implements this case.
>> >> >>>>>>>>
>> >> >>>>>>>> -- Rob
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>> Thanks.
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>>> Robbie
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> ------------------------------------------------------------
>> >> >>>>>>>>>>
>> >> >>>>>>>>> ---------
>> >> >>>>>>
>> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>> ------------------------------------------------------------
>> >> >>>>>>>>> ---------
>> >> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> ------------------------------------------------------------
>> >> ---------
>> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>>>>>>
>> >> >>>>>>
>> >> >>>>>> ------------------------------------------------------------
>> >> ---------
>> >> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>> ------------------------------------------------------------
>> ---------
>> >> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>>>
>> >> >>>>
>> >> >>> ------------------------------------------------------------
>> ---------
>> >> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >>> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>>
>> >> >>>
>> >> >> ------------------------------------------------------------
>> ---------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> For additional commands, e-mail: users-help@qpid.apache.org
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Adel Boutros <Ad...@live.com>.
Hello guys,
My basic JMS API is almost ready. I will share it with you soon to have your feedback.
However, I tried one last thing by getting a random queue name and using it as management reply queue to allow multiple configuration sessions simultaneously but it didn't work.
//This doesn't work and crashes the dispatch router
TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
replyToQueue = managementSession.createQueue(temporaryQueue.getQueueName());
managementConsumer = managementSession.createConsumer(replyToQueue);
//This is the only thing working
replyToQueue = managementSession.createQueue("HARD_CODED_REPLY_QUEUE");
managementConsumer = managementSession.createConsumer(replyToQueue);
Can I have your input on the above?
Regards,
Adel
________________________________
From: Rob Godfrey <ro...@gmail.com>
Sent: Wednesday, February 15, 2017 4:46:59 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
On 15 February 2017 at 16:07, Robbie Gemmell <ro...@gmail.com>
wrote:
> On 15 February 2017 at 14:15, Adel Boutros <Ad...@live.com> wrote:
> > Hello guys,
> >
> >
> > Based on the discussion, we are currently writing a Java API based on
> JMS to configure the dispatch router. I have so far managed to do the
> following:
> >
> > * Create, Read, Delete addresses
> >
> > * Create, Read, Delete connectors
> >
> >
> > Config:
> >
> > Dispatch Router 0.7.0
> >
> > JMS 0.11.1
> >
> >
> > And I have noticed some problems and differences:
> >
> >
> > 1) It seems some calls return ObjectMessage and some TextMessage (This
> is on the side of the consumer in the replyTo)
> >
> > For example, creating twice the same queue will fail but the second call
> will return a JmsTextMessage with an empty body and status code 400
> >
>
> The client treats messages with an amqp-value sectioning containing
> null/nothing as a TextMessage with null value if they arent annotated
> to say otherwise, I'd guess thats where that comes from.
>
> >
> > 2) Returned statusCode differs between Connector and Address
> >
> > Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
> >
> >
> > * Connector operations return java.lang.Long
> > * Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
> >
>
> The router is presumably sending different values back for the
> different operations here, a long and a uint. The router should
> perhaps be consistent, and the client should perhaps not be returning
> the uint object either way.
>
> The last draft of the management spec seems to say the status code
> should be 'integer', im not clear if it means int (not uint)
> specifically, or just any integral type value.
>
>
The specification should definitely say which type should - so we'll fix
that in the next draft. I'd suggest we should int (in AMQP terms) leading
to a java.lang.Integer type in the property you see through Java.
-- Rob
> >
> > 3) Create connector twice makes dispatch router crash. I don't have the
> issue when creating addresses.
> > On the second create call, JMS client receives a normal reply
> containing a statusCode of an exception. After I close the connection to
> the dispatch router via JMS (connection.close), I have the below crash
> >
> > (gdb) where
> > #0 0x00007f27194448a5 in raise () from /lib64/libc.so.6
> > #1 0x00007f2719446085 in abort () from /lib64/libc.so.6
> > #2 0x00007f27194827b7 in __libc_message () from /lib64/libc.so.6
> > #3 0x00007f27194880e6 in malloc_printerr () from /lib64/libc.so.6
> > #4 0x00007f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf
> expression opcode 0xf3
> > ) at /qpid-dispatch-0.7.0/src/hash.c:320
> > #5 0x00007f271a42247d in qdr_route_check_id_for_deletion_CT
> (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
> > ) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
> > #6 0x00007f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30,
> action=Unhandled dwarf expression opcode 0xf3
> > ) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
> > #7 0x00007f271a423f30 in router_core_thread (arg=0x13d2d30) at
> /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
> > #8 0x00007f2719f8c851 in start_thread () from /lib64/libpthread.so.0
> > #9 0x00007f27194fa90d in clone () from /lib64/libc.so.6
> >
> >
> > Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE:
> org.apache.qpid.dispatch.connector: Duplicate value 'connector/
> 127.0.0.1:5915:dispatch_management_connector_test' for unique attribute
> 'identity'
> > *** glibc detected *** /Dispatch/sbin/qdrouterd: double free or
> corruption (fasttop): 0x00007f2708033f10 ***
> > ======= Backtrace: =========
> > /lib64/libc.so.6(+0x760e6)[0x7f27194880e6]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> .so(qd_hash_remove_by_handle+0x29)[0x7f271a40f109]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> .so(+0x3547d)[0x7f271a42247d]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> .so(+0x318d3)[0x7f271a41e8d3]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> .so(router_core_thread+0x230)[0x7f271a423f30]
> > /lib64/libpthread.so.0(+0x7851)[0x7f2719f8c851]
> > /lib64/libc.so.6(clone+0x6d)[0x7f27194fa90d]
> > ======= Memory map: ========
> > 00400000-00403000 r-xp 00000000 fd:01 7735642
> /Dispatch/sbin/qdrouterd
> > 00603000-00604000 rw-p 00003000 fd:01 7735642
> /Dispatch/sbin/qdrouterd
> > 01113000-01458000 rw-p 00000000 00:00 0
> [heap]
> > 7f26f8000000-7f26f805c000 rw-p 00000000 00:00 0
> > 7f26f805c000-7f26fc000000 ---p 00000000 00:00 0
> > 7f26fc000000-7f26fc043000 rw-p 00000000 00:00 0
> > 7f26fc043000-7f2700000000 ---p 00000000 00:00 0
> > 7f2700000000-7f2700085000 rw-p 00000000 00:00 0
> > 7f2700085000-7f2704000000 ---p 00000000 00:00 0
> > 7f27073e9000-7f27073ff000 r-xp 00000000 fd:00 524293
> /lib64/libgcc_s-4.4.7-20120601.so.1
> > 7f27073ff000-7f27075fe000 ---p 00016000 fd:00 524293
> /lib64/libgcc_s-4.4.7-20120601.so.1
> > 7f27075fe000-7f27075ff000 rw-p 00015000 fd:00 524293
> /lib64/libgcc_s-4.4.7-20120601.so.1
> > 7f27075ff000-7f2707600000 ---p 00000000 00:00 0
> > 7f2707600000-7f2708000000 rw-p 00000000 00:00 0
> > 7f2708000000-7f270805a000 rw-p 00000000 00:00 0
> > 7f270805a000-7f270c000000 ---p 00000000 00:00 0
> > 7f270c04a000-7f270c04f000 r-xp 00000000 fd:00 524322
> /lib64/libnss_dns-2.12.so
> > 7f270c04f000-7f270c24e000 ---p 00005000 fd:00 524322
> /lib64/libnss_dns-2.12.so
> > 7f270c24e000-7f270c24f000 r--p 00004000 fd:00 524322
> /lib64/libnss_dns-2.12.so
> > 7f270c24f000-7f270c250000 rw-p 00005000 fd:00 524322
> /lib64/libnss_dns-2.12.so
> > 7f270c250000-7f270c251000 ---p 00000000 00:00 0
> > 7f270c251000-7f270cc51000 rw-p 00000000 00:00 0
> > 7f270cc51000-7f270cc52000 ---p 00000000 00:00 0
> > 7f270cc52000-7f270d652000 rw-p 00000000 00:00 0
> > 7f270d652000-7f270d65e000 r-xp 00000000 fd:00 524324
> /lib64/libnss_files-2.12.so
> > 7f270d65e000-7f270d85e000 ---p 0000c000 fd:00 524324
> /lib64/libnss_files-2.12.so
> > 7f270d85e000-7f270d85f000 r--p 0000c000 fd:00 524324
> /lib64/libnss_files-2.12.so
> > 7f270d85f000-7f270d860000 rw-p 0000d000 fd:00 524324
> /lib64/libnss_files-2.12.so
> > 7f270d86a000-7f270d86b000 ---p 00000000 00:00 0
> > 7f270d86b000-7f270e3ac000 rw-p 00000000 00:00 0
> > 7f270e3ac000-7f270e3b1000 r-xp 00000000 00:16 4090944
> /python278/lib/python2.7/lib-dynload/select.so
> > 7f270e3b1000-7f270e5b0000 ---p 00005000 00:16 4090944
> /python278/lib/python2.7/lib-dynload/select.so
> > 7f270e5b0000-7f270e5b2000 rw-p 00004000 00:16 4090944
> /python278/lib/python2.7/lib-dynload/select.so
> > 7f270e5b2000-7f270e5b6000 r-xp 00000000 00:16 5568743
> /python278/lib/python2.7/lib-dynload/_lsprof.so
> > 7f270e5b6000-7f270e7b5000 ---p 00004000 00:16 5568743
> /python278/lib/python2.7/lib-dynload/_lsprof.so
> > 7f270e7b5000-7f270e7b6000 rw-p 00003000 00:16 5568743
> /python278/lib/python2.7/lib-dynload/_lsprof.so
> > 7f270e7b6000-7f270e8b7000 rw-p 00000000 00:00 0
> > 7f270e8b7000-7f270e8bc000 r-xp 00000000 00:16 6394000
> /python278/lib/python2.7/lib-dynload/strop.so
> > 7f270e8bc000-7f270eabb000 ---p 00005000 00:16 6394000
> /python278/lib/python2.7/lib-dynload/strop.so
> > 7f270eabb000-7f270eabd000 rw-p 00004000 00:16 6394000
> /python278/lib/python2.7/lib-dynload/strop.so
> > 7f270eabd000-7f270eafd000 rw-p 00000000 00:00 0
> > 7f270eafd000-7f270eb00000 r-xp 00000000 00:16 5568749
> /python278/lib/python2.7/lib-dynload/fcntl.so
> > 7f270eb00000-7f270ecff000 ---p 00003000 00:16 5568749
> /python278/lib/python2.7/lib-dynload/fcntl.so
> > 7f270ecff000-7f270ed01000 rw-p 00002000 00:16 5568749
> /python278/lib/python2.7/lib-dynload/fcntl.so
> > 7f270ed01000-7f270ed04000 r-xp 00000000 00:16 5568739
> /python278/lib/python2.7/lib-dynload/_random.so
> > 7f270ed04000-7f270ef03000 ---p 00003000 00:16 5568739
> /python278/lib/python2.7/lib-dynload/_random.so
> > 7f270ef03000-7f270ef04000 rw-p 00002000 00:16 5568739
> /python278/lib/python2.7/lib-dynload/_random.so
> > 4272 Aborted (core dumped)
> >
> >
> > Regards,
> > Adel
> >
> >
> > ________________________________
> > From: Rob Godfrey <ro...@gmail.com>
> > Sent: Monday, February 6, 2017 7:09 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >
> > On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
> > wrote:
> >
> >> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com>
> wrote:
> >> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
> >> >
> >> >> It seems odd that the client creates a _sender_ to the temporary
> queue
> >> >> that it will never send messages _to_ but will receive messages
> _from_.
> >> >>
> >> >>
> >> > This is because JMS semantics require the temporary node to have a
> >> lifetime
> >> > scoped to the session (not a link), so the JMS client has to create a
> >> > synthetic link which it uses simply to manage the lifetime of the
> dynamic
> >> > node. In order to not cause unintentional assigning of messages to a
> >> link
> >> > that will never actually be used for consumption, a sending link is
> used.
> >> > Note that in general JMS would expect that you should be able to send
> to
> >> a
> >> > temporary queue created in this way (since the point of temporary
> queues
> >> is
> >> > to use as a reply to)
> >> >
> >>
> >> Not really important here, but the lifetime is scoped to the
> >> Connection, not Session (agghhh JMS... :P)
> >>
> >
> > That's what I thought I was typing... obviously my fingers were not
> > cooperating with my brain at that point :-)
> >
> > -- Rob
> >
> >
> >>
> >> >
> >> >> Anyway, when the client creates a receiver with a dynamic source
> (and no
> >> >> dynamic-node-properties), the router will accept the link and assign
> a
> >> >> temporary address as the source. This is only useful in this use
> case
> >> if
> >> >> the broker has a way of knowing that the temporary address is
> reachable
> >> via
> >> >> the router network.
> >> >>
> >> >> There is a way to route dynamic termini to a broker. If an
> >> >> x-opt-qd.address property is included in the dynamic-node-properties,
> >> this
> >> >> address will be used to route the attach to the broker. I've never
> >> tested
> >> >> this with a dynamic target in a sender. It might not work.
> >> >
> >> >
> >> > And this really isn't something you'd be expecting a generic client
> (like
> >> > the JMS client) to know :-)
> >> >
> >> > -- Rob
> >> >
> >> >
> >> >>
> >> >>
> >> >> -Ted
> >> >>
> >> >>
> >> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
> >> >>
> >> >>> I've had a look at this. It would seem that Dispatch doesn't like
> what
> >> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
> >> >>> very nice way, and the client then doesnt notice that things have
> gone
> >> >>> south in a somewhat unexpected way.
> >> >>>
> >> >>> The client opens a sending link with 'dynamic' target in order to
> >> >>> create a dynamic node for use as a TemporaryQueue
> address/destination
> >> >>> object, which specific consumers/producers are then created against
> by
> >> >>> the application. Dispatch doesn't seem to like that but erroneously
> >> >>> attaches the link 'successfully', though doesnt set a target address
> >> >>> as is expected. The client then doesnt notice this happened (its
> >> >>> checking for the link being refused, which it wasn't), allowing the
> >> >>> application to proceed as far as creating consumers/procuers using
> the
> >> >>> TemporaryQueue object, with creation of the e.g Consumer then
> failing
> >> >>> since the attach doesnt contain the needed information and leads to
> >> >>> Dispatch detaching it with the error (though it again doesnt
> actually
> >> >>> indicate its refusing the link during the attach response, as it
> >> >>> probably should have in this case).
> >> >>>
> >> >>> Making the client detect the current failure and having it throw an
> >> >>> aexception from createTemporaryQueue is simple enough.
> >> >>>
> >> >>> Hacking the client to use a dynamic recieving link instead, an
> address
> >> >>> was returned by Dispatch in the attach response as expected,
> however a
> >> >>> consumer on the resulting TemporaryQueue object using this address
> >> >>> still didnt get the message I sent to the same place. If I also gave
> >> >>> some credit on the link backing the TemporaryQeueue object itself
> then
> >> >>> that link gets sent the message by Dispatch, though this of no use
> for
> >> >>> the JMS client.
> >> >>>
> >> >>> Needs some more investigation, and I'll need to discuss with some
> >> >>> folks more familiar with Dispatch.
> >> >>>
> >> >>> Robbie
> >> >>>
> >> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
> >> wrote:
> >> >>>
> >> >>>> Hello Robbie,
> >> >>>>
> >> >>>>
> >> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the
> reply
> >> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS
> Client.
> >> >>>>
> >> >>>>
> >> >>>> PS: As Rabih stated before, we are using the same connection and
> same
> >> >>>> session to create the JMSProducer for the request and the
> >> JMSConsumer for
> >> >>>> the reply.
> >> >>>>
> >> >>>>
> >> >>>> Exception
> >> >>>> -------------------
> >> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed
> due
> >> to
> >> >>>> an unrecoverable error.
> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
> >> >>>> eConsumer.java:330)
> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
> >> >>>> sumer.java:196)
> >> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> >> >>>> ssorImpl.java:62)
> >> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> >> >>>> thodAccessorImpl.java:43)
> >> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
> >> >>>> at com.intellij.rt.execution.application.AppMain.main(
> >> AppMain.java:147)
> >> >>>> Caused by: javax.jms.JMSException: No route to the destination node
> >> >>>> [condition = qd:no-route-to-dest]
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >> >>>> tion(AmqpSupport.java:150)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >> >>>> tion(AmqpSupport.java:105)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
> >> >>>> elyClosed(AmqpAbstractResource.java:147)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
> >> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
> >> >>>> s(AmqpProvider.java:795)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
> >> >>>> mqpProvider.java:90)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
> >> >>>> ovider.java:699)
> >> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
> >> >>>> Executors.java:511)
> >> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
> >> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> >> >>>> Executor.java:1142)
> >> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> >> >>>> lExecutor.java:617)
> >> >>>> at java.lang.Thread.run(Thread.java:745)
> >> >>>>
> >> >>>>
> >> >>>> -------------------
> >> >>>> Dispatch Router (PN_TRACE_FRM=1)
> >> >>>> -------------------
> >> >>>>
> >> >>>> [832220]: <- SASL
> >> >>>> [832220]: -> SASL
> >> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
> >> >>>> MBOL[:ANONYMOUS]]
> >> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
> >> >>>> initial-response=b"", hostname="host-name"]
> >> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
> >> >>>> [832220]: <- AMQP
> >> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
> >> a334-44c3-954a-2dd910161411:1",
> >> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
> >> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
> >> >>>> L[:"sole-connection-for-container"],
> properties={:product="QpidJMS",
> >> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
> >> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
> >> >>>> [832220]: -> AMQP
> >> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
> >> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> >> >>>> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-
> >> dispatch-router",
> >> >>>> :version="0.7.0"}]
> >> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> >> >>>> outgoing-window=2147483647, handle-max=65535]
> >> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
> >> >>>> incoming-window=61, outgoing-window=2147483647]
> >> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> >> >>>> outgoing-window=2147483647, handle-max=65535]
> >> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
> >> >>>> incoming-window=61, outgoing-window=2147483647]
> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
> source=@source(40)
> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
> durable=0,
> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list",
> :"amqp:rejected:list"]],
> >> >>>> target=@target(41) [address="$management", durable=0,
> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
> >> >>>> initial-delivery-count=0]
> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
> durable=0,
> >> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:acc
> epted:list",
> >> >>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
> >> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
> >> queue]],
> >> >>>> initial-delivery-count=0, max-message-size=0]
> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> delivery-count=0,
> >> >>>> link-credit=250, drain=false]
> >> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
> source=@source(40)
> >> [],
> >> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
> >> timeout=0,
> >> >>>> dynamic=true, dynamic-node-properties={:"lif
> >> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
> >> temporary-queue"]],
> >> >>>> incomplete-unsettled=false, initial-delivery-count=0]
> >> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> >> role=true,
> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [durable=0,
> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
> >> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43)
> []},
> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
> >> initial-delivery-count=0,
> >> >>>> max-message-size=0]
> >> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> delivery-count=0,
> >> >>>> link-credit=250, drain=false]
> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
> role=true,
> >> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> [durable=0,
> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> >> >>>> default-outcome=@modified(39) [delivery-failed=true],
> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> >> >>>> :"amqp:released:list", :"amqp:modified:list"],
> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41)
> []]
> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
> role=false,
> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [durable=0,
> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> timeout=0,
> >> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
> >> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
> >> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
> >> >>>> destination node"]]
> >> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
> >> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
> >> delivery-tag=b"0",
> >> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
> >> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
> >> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
> >> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
> >> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
> >> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
> >> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
> >> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
> >> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
> >> >>>> x04addr\xa1\x0dbrokerMachine"
> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> delivery-count=1,
> >> >>>> link-credit=250, drain=false]
> >> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
> >> >>>> settled=true, state=@accepted(36) []]
> >> >>>> [832220]:0 <- @close(24) []
> >> >>>> [832220]: <- EOS
> >> >>>> [832220]:0 -> @close(24) []
> >> >>>> [832220]: -> EOS
> >> >>>> Closed x.x.x.x:8961
> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >> >>>>
> >> >>>> ------------------
> >> >>>> JMS Client (PN_TRACE_FRM=1)
> >> >>>> ------------------
> >> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
> >> 4a22-9b22-69d27a017a83:1',
> >> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
> >> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
> >> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
> >> connection-for-container],
> >> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM:
> 1.8.0_111,
> >> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
> >> >>>> [1244186219:0] <- Open{ containerId='router.10200',
> hostname='null',
> >> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
> >> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
> >> ANONYMOUS-RELAY],
> >> >>>> desiredCapabilities=null, properties={product=qpid-dispa
> tch-router,
> >> >>>> version=0.7.0}}
> >> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
> handle=0,
> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> >> 3293ffc57168:1:1:1',
> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> >> amqp:rejected:list],
> >> >>>> capabilities=null}, target=Target{address='$management',
> >> durable=NONE,
> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> >> maxMessageSize=null,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
> handle=0,
> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> >> 3293ffc57168:1:1:1',
> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> >> amqp:rejected:list],
> >> >>>> capabilities=null}, target=Target{address='$management',
> >> durable=NONE,
> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> deliveryCount=0,
> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> properties=null}
> >> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE,
> expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> outcomes=null,
> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> >> maxMessageSize=null,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE,
> expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> outcomes=null,
> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> deliveryCount=0,
> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> properties=null}
> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE,
> expiryPolicy=LINK_DETACH,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
> >> deliveryFailed=true,
> >> >>>> undeliverableHere=null, messageAnnotations=null},
> >> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list,
> amqp:released:list,
> >> >>>> amqp:modified:list], capabilities=[temporary-queue]},
> >> >>>> target=Target{address='null', durable=NONE,
> expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> capabilities=null},
> >> >>>> unsettled=null, incompleteUnsettled=false,
> initialDeliveryCount=null,
> >> >>>> maxMessageSize=null, offeredCapabilities=null,
> >> desiredCapabilities=null,
> >> >>>> properties=null}
> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE,
> expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> outcomes=null,
> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
> >> >>>> error=Error{condition=qd:no-route-to-dest, description='No route
> to
> >> the
> >> >>>> destination node', info=null}}
> >> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
> >> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
> >> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
> >> state=null,
> >> >>>> resume=false, aborted=false, batchable=false} (312)
> >> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
> >> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
> >> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$man
> agement@
> >> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
> >> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
> >> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
> >> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
> >> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
> >> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
> >> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> deliveryCount=1,
> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> properties=null}
> >> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
> >> >>>> settled=true, state=Accepted{}, batchable=false}
> >> >>>> [1244186219:0] -> Close{error=null}
> >> >>>> [1244186219:0] <- Close{error=null}
> >> >>>>
> >> >>>> Regards,
> >> >>>>
> >> >>>> Adel
> >> >>>>
> >> >>>> ________________________________
> >> >>>> From: Robbie Gemmell <ro...@gmail.com>
> >> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
> >> >>>> To: users@qpid.apache.org
> >> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >> >>>>
> >> >>>> That looks fine at first glance. Its possible there is an issue in
> >> >>>> there needing looked it. I am travelling this week so may not get
> to
> >> >>>> look until afterwards, but will try to give things a look at. If
> you
> >> >>>> could give more detail on the exception and maybe a protocol trace
> >> >>>> that might be useful.
> >> >>>>
> >> >>>> Robbie
> >> >>>>
> >> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com>
> wrote:
> >> >>>>
> >> >>>>> Hello Robbie,
> >> >>>>>
> >> >>>>> Thanks for you for your answer.
> >> >>>>> I will try the solutions you proposed.
> >> >>>>>
> >> >>>>> I need just need one clarification. Concerning the Jms, I already
> >> tried
> >> >>>>> to
> >> >>>>> use a temporary queue but it didn't work. May be i am using it
> wrong.
> >> >>>>> Here
> >> >>>>> is what i did:
> >> >>>>>
> >> >>>>> ...
> >> >>>>> Session session = connection.createSession(false,
> >> >>>>> Session.AUTO_ACKNOWLEDGE);
> >> >>>>> Queue queue = session.createQueue("$management");
> >> >>>>> MessageProducer producer = session.createProducer(queue);
> >> >>>>>
> >> >>>>> Queue tempDest = session.createTemporaryQueue();
> >> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDes
> t);
> >> >>>>> connection.start();
> >> >>>>>
> >> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
> >> >>>>> objectMessage.setJMSReplyTo(tempDest);
> >> >>>>> //fill the rest of the parameters ...
> >> >>>>> producer.send(objectMessage);
> >> >>>>> ObjectMessage replyMessage = (ObjectMessage)
> >> >>>>> responseConsumer.receive(1000);
> >> >>>>> ...
> >> >>>>>
> >> >>>>> I was getting an exception on the .receive() from the dispatch
> router
> >> >>>>> saying that the reply-to address is bad...
> >> >>>>> Should i create the temporary queue and the consumer from a
> different
> >> >>>>> session then the producer?
> >> >>>>>
> >> >>>>> Best regards,
> >> >>>>> Rabih
> >> >>>>>
> >> >>>>>
> >> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
> >> >>>>> robbie.gemmell@gmail.com>
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>> The session.createTemporaryQueue(); method is how JMS creates
> >> >>>>>> temporary destinations for use in reply-to scenarios. The
> dispatch
> >> >>>>>> tools will be doing essentially the same thing under the covers
> for
> >> >>>>>> theirs.
> >> >>>>>>
> >> >>>>>> Both work by creating a 'dynamic' link attachment, with the
> server
> >> >>>>>> returning an address for the dynamic attach to the client. One
> key
> >> >>>>>> difference is with JMS you create the temporary destination (for
> >> which
> >> >>>>>> the client uses a dynamic sender link to create), then separately
> >> >>>>>> create a receiver using it (and in turn the address associated
> with
> >> >>>>>> it), whereas non-JMS client/tools will typically just create a
> >> single
> >> >>>>>> dynamic receiver link and use its address for the reply-to.
> >> >>>>>>
> >> >>>>>> For proton-j, there aren't any examples for this, but you you
> >> >>>>>> essentially would change the link opening to not specify an
> address,
> >> >>>>>> and instead set the source(for a receiver) or target (for a
> sender)
> >> to
> >> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
> >> remoteTarget
> >> >>>>>> once the link had been reemotely attached, and get its
> >> >>>>>> (server-generated) address, then use this as your reply-to.
> >> >>>>>>
> >> >>>>>> Robbie
> >> >>>>>>
> >> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
> >> wrote:
> >> >>>>>>
> >> >>>>>>> Hello,
> >> >>>>>>>
> >> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like
> you
> >> >>>>>>> suggested, it worked.
> >> >>>>>>> But I cheated a little to make it work because I did not find a
> >> way in
> >> >>>>>>>
> >> >>>>>> JMS
> >> >>>>>>
> >> >>>>>>> to create a local queue. So I created a queue on the
> qpid-dispatch
> >> and
> >> >>>>>>>
> >> >>>>>> read
> >> >>>>>>
> >> >>>>>>> the result from it. You can check the attached code.
> >> >>>>>>>
> >> >>>>>>> Is there any way using qpid-jms to create a local queue on the
> >> client
> >> >>>>>>>
> >> >>>>>> side
> >> >>>>>>
> >> >>>>>>> to serve as a reply to address?
> >> >>>>>>>
> >> >>>>>>> For the proton-j test, I have the same question as above. I saw
> >> that
> >> >>>>>>> it
> >> >>>>>>>
> >> >>>>>> can
> >> >>>>>>
> >> >>>>>>> be done with the C++ API. Are there any examples for proton-j or
> >> >>>>>>>
> >> >>>>>> something
> >> >>>>>>
> >> >>>>>>> that can help me?
> >> >>>>>>>
> >> >>>>>>> I saw may be in proton we don't need a local queue, may be we
> can
> >> get
> >> >>>>>>> the
> >> >>>>>>> address of the consumer directly and pass it in reply-to field.
> Is
> >> it
> >> >>>>>>> correct?
> >> >>>>>>>
> >> >>>>>>> Thanks,
> >> >>>>>>> Rabih
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
> >> >>>>>>> rob.j.godfrey@gmail.com>
> >> >>>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gmurthy@redhat.com
> >
> >> >>>>>>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> ----- Original Message -----
> >> >>>>>>>>>
> >> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
> >> >>>>>>>>>> To: users@qpid.apache.org
> >> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
> >> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid
> >> Jms
> >> >>>>>>>>>>
> >> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
> >> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you
> >> told
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>> me
> >> >>>>>>
> >> >>>>>>> Robbie and it worked.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> But like the proton-j case, the connector is not being
> >> created on
> >> >>>>>>>>>>>> the
> >> >>>>>>>>>>>> Qpid-dispatch side.
> >> >>>>>>>>>>>> I attached the amqp communication into this mail.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> The last frame in that file is incomplete (the previous
> error
> >> >>>>>>>>>>>
> >> >>>>>>>>>> regarding the
> >> >>>>>>>>>
> >> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
> >> frame
> >> >>>>>>>>>>>
> >> >>>>>>>>>> is
> >> >>>>>>
> >> >>>>>>> likely
> >> >>>>>>>>>
> >> >>>>>>>>>> the response which would indicate the success or otherwise of
> >> the
> >> >>>>>>>>>>>
> >> >>>>>>>>>> frame. Is
> >> >>>>>>>>>
> >> >>>>>>>>>> there anything logged by the router?
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
> >> simpler
> >> >>>>>>>>>>> for
> >> >>>>>>>>>>>
> >> >>>>>>>>>> this
> >> >>>>>>>>>
> >> >>>>>>>>>> sort of thing in my view.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more
> helpful.
> >> >>>>>>>>>> You
> >> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
> >> since
> >> >>>>>>>>>> it
> >> >>>>>>>>>> uses proton-j.
> >> >>>>>>>>>>
> >> >>>>>>>>>> One key difference from the qdmanage case is you are not
> >> setting a
> >> >>>>>>>>>> reply-to value or correlation-id to use along with it. I
> don't
> >> know
> >> >>>>>>>>>>
> >> >>>>>>>>> if
> >> >>>>>>
> >> >>>>>>> the router cares about not being able to send a response or not
> >> >>>>>>>>>> though, but it might.
> >> >>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> You could add the following to your dispatch router conf file
> >> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable
> trace
> >> >>>>>>>>>
> >> >>>>>>>> logging)
> >> >>>>>>
> >> >>>>>>>
> >> >>>>>>>>> log {
> >> >>>>>>>>> module: DEFAULT
> >> >>>>>>>>> enable: trace+
> >> >>>>>>>>> output: /path/to/log/qdrouterd.log
> >> >>>>>>>>> }
> >> >>>>>>>>>
> >> >>>>>>>>> When you run your management request, you will see proton
> frame
> >> >>>>>>>>> trace
> >> >>>>>>>>> and
> >> >>>>>>>>> you will see additional logging out of the dispatch Python
> agent
> >> -
> >> >>>>>>>>> something like the following -
> >> >>>>>>>>>
> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
> >> >>>>>>>>> Message(address=None,
> >> >>>>>>>>> properties={'operation': 'CREATE', 'type':
> >> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
> >> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
> >> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
> >> >>>>>>>>>
> >> >>>>>>>> 'rabih.connector'},
> >> >>>>>>
> >> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
> >> >>>>>>>>> correlation_id=1L)
> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
> >> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
> >> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True,
> cost=1,
> >> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
> >> 5673:rabih.connector,
> >> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
> >> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
> >> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.
> connector,
> >> >>>>>>>>> verifyHostName=True)
> >> >>>>>>>>>
> >> >>>>>>>>> The Python management agent will not process your request if
> >> there
> >> >>>>>>>>> is
> >> >>>>>>>>>
> >> >>>>>>>> no
> >> >>>>>>
> >> >>>>>>> reply_to as seen here -
> >> >>>>>>>>>
> >> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
> >> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
> >> because
> >> >>>>>>>> there
> >> >>>>>>>> is
> >> >>>>>>>> a reply-to doesn't mean that the sender will be around to
> actually
> >> >>>>>>>> hear
> >> >>>>>>>> the
> >> >>>>>>>> reply, so it seems a bit arbitrary to say that because we
> *know*
> >> the
> >> >>>>>>>> sender
> >> >>>>>>>> won't learn of the outcome that we won't do anything... The
> spec
> >> >>>>>>>> draft
> >> >>>>>>>> doesn't currently say anything about this (obviously it should
> >> do),
> >> >>>>>>>> but
> >> >>>>>>>>
> >> >>>>>>> my
> >> >>>>>>
> >> >>>>>>> expectation would certainly be that a request would be processed
> >> even
> >> >>>>>>>> if
> >> >>>>>>>> the replyTo address was not present (or ended up not routing
> >> >>>>>>>> anywhere).
> >> >>>>>>>> This is also how the Qpid Broker for Java implements this case.
> >> >>>>>>>>
> >> >>>>>>>> -- Rob
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> Thanks.
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>> Robbie
> >> >>>>>>>>>>
> >> >>>>>>>>>> ------------------------------------------------------------
> >> >>>>>>>>>>
> >> >>>>>>>>> ---------
> >> >>>>>>
> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>> ------------------------------------------------------------
> >> >>>>>>>>> ---------
> >> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> ------------------------------------------------------------
> >> ---------
> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> ------------------------------------------------------------
> >> ---------
> >> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>> ------------------------------------------------------------
> ---------
> >> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>
> >> >>>>
> >> >>> ------------------------------------------------------------
> ---------
> >> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>
> >> >>>
> >> >> ------------------------------------------------------------
> ---------
> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Rob Godfrey <ro...@gmail.com>.
On 15 February 2017 at 16:07, Robbie Gemmell <ro...@gmail.com>
wrote:
> On 15 February 2017 at 14:15, Adel Boutros <Ad...@live.com> wrote:
> > Hello guys,
> >
> >
> > Based on the discussion, we are currently writing a Java API based on
> JMS to configure the dispatch router. I have so far managed to do the
> following:
> >
> > * Create, Read, Delete addresses
> >
> > * Create, Read, Delete connectors
> >
> >
> > Config:
> >
> > Dispatch Router 0.7.0
> >
> > JMS 0.11.1
> >
> >
> > And I have noticed some problems and differences:
> >
> >
> > 1) It seems some calls return ObjectMessage and some TextMessage (This
> is on the side of the consumer in the replyTo)
> >
> > For example, creating twice the same queue will fail but the second call
> will return a JmsTextMessage with an empty body and status code 400
> >
>
> The client treats messages with an amqp-value sectioning containing
> null/nothing as a TextMessage with null value if they arent annotated
> to say otherwise, I'd guess thats where that comes from.
>
> >
> > 2) Returned statusCode differs between Connector and Address
> >
> > Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
> >
> >
> > * Connector operations return java.lang.Long
> > * Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
> >
>
> The router is presumably sending different values back for the
> different operations here, a long and a uint. The router should
> perhaps be consistent, and the client should perhaps not be returning
> the uint object either way.
>
> The last draft of the management spec seems to say the status code
> should be 'integer', im not clear if it means int (not uint)
> specifically, or just any integral type value.
>
>
The specification should definitely say which type should - so we'll fix
that in the next draft. I'd suggest we should int (in AMQP terms) leading
to a java.lang.Integer type in the property you see through Java.
-- Rob
> >
> > 3) Create connector twice makes dispatch router crash. I don't have the
> issue when creating addresses.
> > On the second create call, JMS client receives a normal reply
> containing a statusCode of an exception. After I close the connection to
> the dispatch router via JMS (connection.close), I have the below crash
> >
> > (gdb) where
> > #0 0x00007f27194448a5 in raise () from /lib64/libc.so.6
> > #1 0x00007f2719446085 in abort () from /lib64/libc.so.6
> > #2 0x00007f27194827b7 in __libc_message () from /lib64/libc.so.6
> > #3 0x00007f27194880e6 in malloc_printerr () from /lib64/libc.so.6
> > #4 0x00007f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf
> expression opcode 0xf3
> > ) at /qpid-dispatch-0.7.0/src/hash.c:320
> > #5 0x00007f271a42247d in qdr_route_check_id_for_deletion_CT
> (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
> > ) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
> > #6 0x00007f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30,
> action=Unhandled dwarf expression opcode 0xf3
> > ) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
> > #7 0x00007f271a423f30 in router_core_thread (arg=0x13d2d30) at
> /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
> > #8 0x00007f2719f8c851 in start_thread () from /lib64/libpthread.so.0
> > #9 0x00007f27194fa90d in clone () from /lib64/libc.so.6
> >
> >
> > Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE:
> org.apache.qpid.dispatch.connector: Duplicate value 'connector/
> 127.0.0.1:5915:dispatch_management_connector_test' for unique attribute
> 'identity'
> > *** glibc detected *** /Dispatch/sbin/qdrouterd: double free or
> corruption (fasttop): 0x00007f2708033f10 ***
> > ======= Backtrace: =========
> > /lib64/libc.so.6(+0x760e6)[0x7f27194880e6]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> .so(qd_hash_remove_by_handle+0x29)[0x7f271a40f109]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> .so(+0x3547d)[0x7f271a42247d]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> .so(+0x318d3)[0x7f271a41e8d3]
> > /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch
> .so(router_core_thread+0x230)[0x7f271a423f30]
> > /lib64/libpthread.so.0(+0x7851)[0x7f2719f8c851]
> > /lib64/libc.so.6(clone+0x6d)[0x7f27194fa90d]
> > ======= Memory map: ========
> > 00400000-00403000 r-xp 00000000 fd:01 7735642
> /Dispatch/sbin/qdrouterd
> > 00603000-00604000 rw-p 00003000 fd:01 7735642
> /Dispatch/sbin/qdrouterd
> > 01113000-01458000 rw-p 00000000 00:00 0
> [heap]
> > 7f26f8000000-7f26f805c000 rw-p 00000000 00:00 0
> > 7f26f805c000-7f26fc000000 ---p 00000000 00:00 0
> > 7f26fc000000-7f26fc043000 rw-p 00000000 00:00 0
> > 7f26fc043000-7f2700000000 ---p 00000000 00:00 0
> > 7f2700000000-7f2700085000 rw-p 00000000 00:00 0
> > 7f2700085000-7f2704000000 ---p 00000000 00:00 0
> > 7f27073e9000-7f27073ff000 r-xp 00000000 fd:00 524293
> /lib64/libgcc_s-4.4.7-20120601.so.1
> > 7f27073ff000-7f27075fe000 ---p 00016000 fd:00 524293
> /lib64/libgcc_s-4.4.7-20120601.so.1
> > 7f27075fe000-7f27075ff000 rw-p 00015000 fd:00 524293
> /lib64/libgcc_s-4.4.7-20120601.so.1
> > 7f27075ff000-7f2707600000 ---p 00000000 00:00 0
> > 7f2707600000-7f2708000000 rw-p 00000000 00:00 0
> > 7f2708000000-7f270805a000 rw-p 00000000 00:00 0
> > 7f270805a000-7f270c000000 ---p 00000000 00:00 0
> > 7f270c04a000-7f270c04f000 r-xp 00000000 fd:00 524322
> /lib64/libnss_dns-2.12.so
> > 7f270c04f000-7f270c24e000 ---p 00005000 fd:00 524322
> /lib64/libnss_dns-2.12.so
> > 7f270c24e000-7f270c24f000 r--p 00004000 fd:00 524322
> /lib64/libnss_dns-2.12.so
> > 7f270c24f000-7f270c250000 rw-p 00005000 fd:00 524322
> /lib64/libnss_dns-2.12.so
> > 7f270c250000-7f270c251000 ---p 00000000 00:00 0
> > 7f270c251000-7f270cc51000 rw-p 00000000 00:00 0
> > 7f270cc51000-7f270cc52000 ---p 00000000 00:00 0
> > 7f270cc52000-7f270d652000 rw-p 00000000 00:00 0
> > 7f270d652000-7f270d65e000 r-xp 00000000 fd:00 524324
> /lib64/libnss_files-2.12.so
> > 7f270d65e000-7f270d85e000 ---p 0000c000 fd:00 524324
> /lib64/libnss_files-2.12.so
> > 7f270d85e000-7f270d85f000 r--p 0000c000 fd:00 524324
> /lib64/libnss_files-2.12.so
> > 7f270d85f000-7f270d860000 rw-p 0000d000 fd:00 524324
> /lib64/libnss_files-2.12.so
> > 7f270d86a000-7f270d86b000 ---p 00000000 00:00 0
> > 7f270d86b000-7f270e3ac000 rw-p 00000000 00:00 0
> > 7f270e3ac000-7f270e3b1000 r-xp 00000000 00:16 4090944
> /python278/lib/python2.7/lib-dynload/select.so
> > 7f270e3b1000-7f270e5b0000 ---p 00005000 00:16 4090944
> /python278/lib/python2.7/lib-dynload/select.so
> > 7f270e5b0000-7f270e5b2000 rw-p 00004000 00:16 4090944
> /python278/lib/python2.7/lib-dynload/select.so
> > 7f270e5b2000-7f270e5b6000 r-xp 00000000 00:16 5568743
> /python278/lib/python2.7/lib-dynload/_lsprof.so
> > 7f270e5b6000-7f270e7b5000 ---p 00004000 00:16 5568743
> /python278/lib/python2.7/lib-dynload/_lsprof.so
> > 7f270e7b5000-7f270e7b6000 rw-p 00003000 00:16 5568743
> /python278/lib/python2.7/lib-dynload/_lsprof.so
> > 7f270e7b6000-7f270e8b7000 rw-p 00000000 00:00 0
> > 7f270e8b7000-7f270e8bc000 r-xp 00000000 00:16 6394000
> /python278/lib/python2.7/lib-dynload/strop.so
> > 7f270e8bc000-7f270eabb000 ---p 00005000 00:16 6394000
> /python278/lib/python2.7/lib-dynload/strop.so
> > 7f270eabb000-7f270eabd000 rw-p 00004000 00:16 6394000
> /python278/lib/python2.7/lib-dynload/strop.so
> > 7f270eabd000-7f270eafd000 rw-p 00000000 00:00 0
> > 7f270eafd000-7f270eb00000 r-xp 00000000 00:16 5568749
> /python278/lib/python2.7/lib-dynload/fcntl.so
> > 7f270eb00000-7f270ecff000 ---p 00003000 00:16 5568749
> /python278/lib/python2.7/lib-dynload/fcntl.so
> > 7f270ecff000-7f270ed01000 rw-p 00002000 00:16 5568749
> /python278/lib/python2.7/lib-dynload/fcntl.so
> > 7f270ed01000-7f270ed04000 r-xp 00000000 00:16 5568739
> /python278/lib/python2.7/lib-dynload/_random.so
> > 7f270ed04000-7f270ef03000 ---p 00003000 00:16 5568739
> /python278/lib/python2.7/lib-dynload/_random.so
> > 7f270ef03000-7f270ef04000 rw-p 00002000 00:16 5568739
> /python278/lib/python2.7/lib-dynload/_random.so
> > 4272 Aborted (core dumped)
> >
> >
> > Regards,
> > Adel
> >
> >
> > ________________________________
> > From: Rob Godfrey <ro...@gmail.com>
> > Sent: Monday, February 6, 2017 7:09 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >
> > On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
> > wrote:
> >
> >> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com>
> wrote:
> >> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
> >> >
> >> >> It seems odd that the client creates a _sender_ to the temporary
> queue
> >> >> that it will never send messages _to_ but will receive messages
> _from_.
> >> >>
> >> >>
> >> > This is because JMS semantics require the temporary node to have a
> >> lifetime
> >> > scoped to the session (not a link), so the JMS client has to create a
> >> > synthetic link which it uses simply to manage the lifetime of the
> dynamic
> >> > node. In order to not cause unintentional assigning of messages to a
> >> link
> >> > that will never actually be used for consumption, a sending link is
> used.
> >> > Note that in general JMS would expect that you should be able to send
> to
> >> a
> >> > temporary queue created in this way (since the point of temporary
> queues
> >> is
> >> > to use as a reply to)
> >> >
> >>
> >> Not really important here, but the lifetime is scoped to the
> >> Connection, not Session (agghhh JMS... :P)
> >>
> >
> > That's what I thought I was typing... obviously my fingers were not
> > cooperating with my brain at that point :-)
> >
> > -- Rob
> >
> >
> >>
> >> >
> >> >> Anyway, when the client creates a receiver with a dynamic source
> (and no
> >> >> dynamic-node-properties), the router will accept the link and assign
> a
> >> >> temporary address as the source. This is only useful in this use
> case
> >> if
> >> >> the broker has a way of knowing that the temporary address is
> reachable
> >> via
> >> >> the router network.
> >> >>
> >> >> There is a way to route dynamic termini to a broker. If an
> >> >> x-opt-qd.address property is included in the dynamic-node-properties,
> >> this
> >> >> address will be used to route the attach to the broker. I've never
> >> tested
> >> >> this with a dynamic target in a sender. It might not work.
> >> >
> >> >
> >> > And this really isn't something you'd be expecting a generic client
> (like
> >> > the JMS client) to know :-)
> >> >
> >> > -- Rob
> >> >
> >> >
> >> >>
> >> >>
> >> >> -Ted
> >> >>
> >> >>
> >> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
> >> >>
> >> >>> I've had a look at this. It would seem that Dispatch doesn't like
> what
> >> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
> >> >>> very nice way, and the client then doesnt notice that things have
> gone
> >> >>> south in a somewhat unexpected way.
> >> >>>
> >> >>> The client opens a sending link with 'dynamic' target in order to
> >> >>> create a dynamic node for use as a TemporaryQueue
> address/destination
> >> >>> object, which specific consumers/producers are then created against
> by
> >> >>> the application. Dispatch doesn't seem to like that but erroneously
> >> >>> attaches the link 'successfully', though doesnt set a target address
> >> >>> as is expected. The client then doesnt notice this happened (its
> >> >>> checking for the link being refused, which it wasn't), allowing the
> >> >>> application to proceed as far as creating consumers/procuers using
> the
> >> >>> TemporaryQueue object, with creation of the e.g Consumer then
> failing
> >> >>> since the attach doesnt contain the needed information and leads to
> >> >>> Dispatch detaching it with the error (though it again doesnt
> actually
> >> >>> indicate its refusing the link during the attach response, as it
> >> >>> probably should have in this case).
> >> >>>
> >> >>> Making the client detect the current failure and having it throw an
> >> >>> aexception from createTemporaryQueue is simple enough.
> >> >>>
> >> >>> Hacking the client to use a dynamic recieving link instead, an
> address
> >> >>> was returned by Dispatch in the attach response as expected,
> however a
> >> >>> consumer on the resulting TemporaryQueue object using this address
> >> >>> still didnt get the message I sent to the same place. If I also gave
> >> >>> some credit on the link backing the TemporaryQeueue object itself
> then
> >> >>> that link gets sent the message by Dispatch, though this of no use
> for
> >> >>> the JMS client.
> >> >>>
> >> >>> Needs some more investigation, and I'll need to discuss with some
> >> >>> folks more familiar with Dispatch.
> >> >>>
> >> >>> Robbie
> >> >>>
> >> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
> >> wrote:
> >> >>>
> >> >>>> Hello Robbie,
> >> >>>>
> >> >>>>
> >> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the
> reply
> >> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS
> Client.
> >> >>>>
> >> >>>>
> >> >>>> PS: As Rabih stated before, we are using the same connection and
> same
> >> >>>> session to create the JMSProducer for the request and the
> >> JMSConsumer for
> >> >>>> the reply.
> >> >>>>
> >> >>>>
> >> >>>> Exception
> >> >>>> -------------------
> >> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed
> due
> >> to
> >> >>>> an unrecoverable error.
> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
> >> >>>> eConsumer.java:330)
> >> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
> >> >>>> sumer.java:196)
> >> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> >> >>>> ssorImpl.java:62)
> >> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> >> >>>> thodAccessorImpl.java:43)
> >> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
> >> >>>> at com.intellij.rt.execution.application.AppMain.main(
> >> AppMain.java:147)
> >> >>>> Caused by: javax.jms.JMSException: No route to the destination node
> >> >>>> [condition = qd:no-route-to-dest]
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >> >>>> tion(AmqpSupport.java:150)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >> >>>> tion(AmqpSupport.java:105)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
> >> >>>> elyClosed(AmqpAbstractResource.java:147)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
> >> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
> >> >>>> s(AmqpProvider.java:795)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
> >> >>>> mqpProvider.java:90)
> >> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
> >> >>>> ovider.java:699)
> >> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
> >> >>>> Executors.java:511)
> >> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> >> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
> >> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> >> >>>> Executor.java:1142)
> >> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> >> >>>> lExecutor.java:617)
> >> >>>> at java.lang.Thread.run(Thread.java:745)
> >> >>>>
> >> >>>>
> >> >>>> -------------------
> >> >>>> Dispatch Router (PN_TRACE_FRM=1)
> >> >>>> -------------------
> >> >>>>
> >> >>>> [832220]: <- SASL
> >> >>>> [832220]: -> SASL
> >> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
> >> >>>> MBOL[:ANONYMOUS]]
> >> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
> >> >>>> initial-response=b"", hostname="host-name"]
> >> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
> >> >>>> [832220]: <- AMQP
> >> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
> >> a334-44c3-954a-2dd910161411:1",
> >> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
> >> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
> >> >>>> L[:"sole-connection-for-container"],
> properties={:product="QpidJMS",
> >> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
> >> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
> >> >>>> [832220]: -> AMQP
> >> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
> >> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> >> >>>> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-
> >> dispatch-router",
> >> >>>> :version="0.7.0"}]
> >> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> >> >>>> outgoing-window=2147483647, handle-max=65535]
> >> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
> >> >>>> incoming-window=61, outgoing-window=2147483647]
> >> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> >> >>>> outgoing-window=2147483647, handle-max=65535]
> >> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
> >> >>>> incoming-window=61, outgoing-window=2147483647]
> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
> source=@source(40)
> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
> durable=0,
> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list",
> :"amqp:rejected:list"]],
> >> >>>> target=@target(41) [address="$management", durable=0,
> >> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
> >> >>>> initial-delivery-count=0]
> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
> >> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> >> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
> durable=0,
> >> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:acc
> epted:list",
> >> >>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
> >> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
> >> queue]],
> >> >>>> initial-delivery-count=0, max-message-size=0]
> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> delivery-count=0,
> >> >>>> link-credit=250, drain=false]
> >> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> >> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0,
> source=@source(40)
> >> [],
> >> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
> >> timeout=0,
> >> >>>> dynamic=true, dynamic-node-properties={:"lif
> >> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
> >> temporary-queue"]],
> >> >>>> incomplete-unsettled=false, initial-delivery-count=0]
> >> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
> >> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> >> role=true,
> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [durable=0,
> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
> >> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43)
> []},
> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
> >> initial-delivery-count=0,
> >> >>>> max-message-size=0]
> >> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> delivery-count=0,
> >> >>>> link-credit=250, drain=false]
> >> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
> role=true,
> >> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> [durable=0,
> >> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> >> >>>> default-outcome=@modified(39) [delivery-failed=true],
> >> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> >> >>>> :"amqp:released:list", :"amqp:modified:list"],
> >> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41)
> []]
> >> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
> >> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1,
> role=false,
> >> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [durable=0,
> >> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> timeout=0,
> >> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
> >> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
> >> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
> >> >>>> destination node"]]
> >> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
> >> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
> >> delivery-tag=b"0",
> >> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
> >> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
> >> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
> >> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
> >> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
> >> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
> >> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
> >> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
> >> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
> >> >>>> x04addr\xa1\x0dbrokerMachine"
> >> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
> >> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> >> delivery-count=1,
> >> >>>> link-credit=250, drain=false]
> >> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
> >> >>>> settled=true, state=@accepted(36) []]
> >> >>>> [832220]:0 <- @close(24) []
> >> >>>> [832220]: <- EOS
> >> >>>> [832220]:0 -> @close(24) []
> >> >>>> [832220]: -> EOS
> >> >>>> Closed x.x.x.x:8961
> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >> >>>>
> >> >>>> ------------------
> >> >>>> JMS Client (PN_TRACE_FRM=1)
> >> >>>> ------------------
> >> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
> >> 4a22-9b22-69d27a017a83:1',
> >> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
> >> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
> >> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
> >> connection-for-container],
> >> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM:
> 1.8.0_111,
> >> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
> >> >>>> [1244186219:0] <- Open{ containerId='router.10200',
> hostname='null',
> >> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
> >> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
> >> ANONYMOUS-RELAY],
> >> >>>> desiredCapabilities=null, properties={product=qpid-dispa
> tch-router,
> >> >>>> version=0.7.0}}
> >> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
> >> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
> handle=0,
> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> >> 3293ffc57168:1:1:1',
> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> >> amqp:rejected:list],
> >> >>>> capabilities=null}, target=Target{address='$management',
> >> durable=NONE,
> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> >> maxMessageSize=null,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
> >> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
> handle=0,
> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> >> 3293ffc57168:1:1:1',
> >> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> >> amqp:rejected:list],
> >> >>>> capabilities=null}, target=Target{address='$management',
> >> durable=NONE,
> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> deliveryCount=0,
> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> properties=null}
> >> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE,
> expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> outcomes=null,
> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> >> maxMessageSize=null,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
> >> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE,
> expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> outcomes=null,
> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> deliveryCount=0,
> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> properties=null}
> >> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE,
> expiryPolicy=LINK_DETACH,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
> >> deliveryFailed=true,
> >> >>>> undeliverableHere=null, messageAnnotations=null},
> >> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list,
> amqp:released:list,
> >> >>>> amqp:modified:list], capabilities=[temporary-queue]},
> >> >>>> target=Target{address='null', durable=NONE,
> expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> capabilities=null},
> >> >>>> unsettled=null, incompleteUnsettled=false,
> initialDeliveryCount=null,
> >> >>>> maxMessageSize=null, offeredCapabilities=null,
> >> desiredCapabilities=null,
> >> >>>> properties=null}
> >> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
> >> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >> >>>> source=Source{address='null', durable=NONE,
> expiryPolicy=SESSION_END,
> >> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> >> outcomes=null,
> >> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> >> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0,
> >> >>>> offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> >> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
> >> >>>> error=Error{condition=qd:no-route-to-dest, description='No route
> to
> >> the
> >> >>>> destination node', info=null}}
> >> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
> >> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
> >> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
> >> state=null,
> >> >>>> resume=false, aborted=false, batchable=false} (312)
> >> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
> >> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
> >> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$man
> agement@
> >> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
> >> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
> >> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
> >> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
> >> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
> >> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
> >> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
> >> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> >> deliveryCount=1,
> >> >>>> linkCredit=250, available=null, drain=false, echo=false,
> >> properties=null}
> >> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
> >> >>>> settled=true, state=Accepted{}, batchable=false}
> >> >>>> [1244186219:0] -> Close{error=null}
> >> >>>> [1244186219:0] <- Close{error=null}
> >> >>>>
> >> >>>> Regards,
> >> >>>>
> >> >>>> Adel
> >> >>>>
> >> >>>> ________________________________
> >> >>>> From: Robbie Gemmell <ro...@gmail.com>
> >> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
> >> >>>> To: users@qpid.apache.org
> >> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >> >>>>
> >> >>>> That looks fine at first glance. Its possible there is an issue in
> >> >>>> there needing looked it. I am travelling this week so may not get
> to
> >> >>>> look until afterwards, but will try to give things a look at. If
> you
> >> >>>> could give more detail on the exception and maybe a protocol trace
> >> >>>> that might be useful.
> >> >>>>
> >> >>>> Robbie
> >> >>>>
> >> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com>
> wrote:
> >> >>>>
> >> >>>>> Hello Robbie,
> >> >>>>>
> >> >>>>> Thanks for you for your answer.
> >> >>>>> I will try the solutions you proposed.
> >> >>>>>
> >> >>>>> I need just need one clarification. Concerning the Jms, I already
> >> tried
> >> >>>>> to
> >> >>>>> use a temporary queue but it didn't work. May be i am using it
> wrong.
> >> >>>>> Here
> >> >>>>> is what i did:
> >> >>>>>
> >> >>>>> ...
> >> >>>>> Session session = connection.createSession(false,
> >> >>>>> Session.AUTO_ACKNOWLEDGE);
> >> >>>>> Queue queue = session.createQueue("$management");
> >> >>>>> MessageProducer producer = session.createProducer(queue);
> >> >>>>>
> >> >>>>> Queue tempDest = session.createTemporaryQueue();
> >> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDes
> t);
> >> >>>>> connection.start();
> >> >>>>>
> >> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
> >> >>>>> objectMessage.setJMSReplyTo(tempDest);
> >> >>>>> //fill the rest of the parameters ...
> >> >>>>> producer.send(objectMessage);
> >> >>>>> ObjectMessage replyMessage = (ObjectMessage)
> >> >>>>> responseConsumer.receive(1000);
> >> >>>>> ...
> >> >>>>>
> >> >>>>> I was getting an exception on the .receive() from the dispatch
> router
> >> >>>>> saying that the reply-to address is bad...
> >> >>>>> Should i create the temporary queue and the consumer from a
> different
> >> >>>>> session then the producer?
> >> >>>>>
> >> >>>>> Best regards,
> >> >>>>> Rabih
> >> >>>>>
> >> >>>>>
> >> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
> >> >>>>> robbie.gemmell@gmail.com>
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>> The session.createTemporaryQueue(); method is how JMS creates
> >> >>>>>> temporary destinations for use in reply-to scenarios. The
> dispatch
> >> >>>>>> tools will be doing essentially the same thing under the covers
> for
> >> >>>>>> theirs.
> >> >>>>>>
> >> >>>>>> Both work by creating a 'dynamic' link attachment, with the
> server
> >> >>>>>> returning an address for the dynamic attach to the client. One
> key
> >> >>>>>> difference is with JMS you create the temporary destination (for
> >> which
> >> >>>>>> the client uses a dynamic sender link to create), then separately
> >> >>>>>> create a receiver using it (and in turn the address associated
> with
> >> >>>>>> it), whereas non-JMS client/tools will typically just create a
> >> single
> >> >>>>>> dynamic receiver link and use its address for the reply-to.
> >> >>>>>>
> >> >>>>>> For proton-j, there aren't any examples for this, but you you
> >> >>>>>> essentially would change the link opening to not specify an
> address,
> >> >>>>>> and instead set the source(for a receiver) or target (for a
> sender)
> >> to
> >> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
> >> remoteTarget
> >> >>>>>> once the link had been reemotely attached, and get its
> >> >>>>>> (server-generated) address, then use this as your reply-to.
> >> >>>>>>
> >> >>>>>> Robbie
> >> >>>>>>
> >> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
> >> wrote:
> >> >>>>>>
> >> >>>>>>> Hello,
> >> >>>>>>>
> >> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like
> you
> >> >>>>>>> suggested, it worked.
> >> >>>>>>> But I cheated a little to make it work because I did not find a
> >> way in
> >> >>>>>>>
> >> >>>>>> JMS
> >> >>>>>>
> >> >>>>>>> to create a local queue. So I created a queue on the
> qpid-dispatch
> >> and
> >> >>>>>>>
> >> >>>>>> read
> >> >>>>>>
> >> >>>>>>> the result from it. You can check the attached code.
> >> >>>>>>>
> >> >>>>>>> Is there any way using qpid-jms to create a local queue on the
> >> client
> >> >>>>>>>
> >> >>>>>> side
> >> >>>>>>
> >> >>>>>>> to serve as a reply to address?
> >> >>>>>>>
> >> >>>>>>> For the proton-j test, I have the same question as above. I saw
> >> that
> >> >>>>>>> it
> >> >>>>>>>
> >> >>>>>> can
> >> >>>>>>
> >> >>>>>>> be done with the C++ API. Are there any examples for proton-j or
> >> >>>>>>>
> >> >>>>>> something
> >> >>>>>>
> >> >>>>>>> that can help me?
> >> >>>>>>>
> >> >>>>>>> I saw may be in proton we don't need a local queue, may be we
> can
> >> get
> >> >>>>>>> the
> >> >>>>>>> address of the consumer directly and pass it in reply-to field.
> Is
> >> it
> >> >>>>>>> correct?
> >> >>>>>>>
> >> >>>>>>> Thanks,
> >> >>>>>>> Rabih
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
> >> >>>>>>> rob.j.godfrey@gmail.com>
> >> >>>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gmurthy@redhat.com
> >
> >> >>>>>>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> ----- Original Message -----
> >> >>>>>>>>>
> >> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
> >> >>>>>>>>>> To: users@qpid.apache.org
> >> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
> >> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid
> >> Jms
> >> >>>>>>>>>>
> >> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
> >> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you
> >> told
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>> me
> >> >>>>>>
> >> >>>>>>> Robbie and it worked.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> But like the proton-j case, the connector is not being
> >> created on
> >> >>>>>>>>>>>> the
> >> >>>>>>>>>>>> Qpid-dispatch side.
> >> >>>>>>>>>>>> I attached the amqp communication into this mail.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> The last frame in that file is incomplete (the previous
> error
> >> >>>>>>>>>>>
> >> >>>>>>>>>> regarding the
> >> >>>>>>>>>
> >> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
> >> frame
> >> >>>>>>>>>>>
> >> >>>>>>>>>> is
> >> >>>>>>
> >> >>>>>>> likely
> >> >>>>>>>>>
> >> >>>>>>>>>> the response which would indicate the success or otherwise of
> >> the
> >> >>>>>>>>>>>
> >> >>>>>>>>>> frame. Is
> >> >>>>>>>>>
> >> >>>>>>>>>> there anything logged by the router?
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
> >> simpler
> >> >>>>>>>>>>> for
> >> >>>>>>>>>>>
> >> >>>>>>>>>> this
> >> >>>>>>>>>
> >> >>>>>>>>>> sort of thing in my view.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more
> helpful.
> >> >>>>>>>>>> You
> >> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
> >> since
> >> >>>>>>>>>> it
> >> >>>>>>>>>> uses proton-j.
> >> >>>>>>>>>>
> >> >>>>>>>>>> One key difference from the qdmanage case is you are not
> >> setting a
> >> >>>>>>>>>> reply-to value or correlation-id to use along with it. I
> don't
> >> know
> >> >>>>>>>>>>
> >> >>>>>>>>> if
> >> >>>>>>
> >> >>>>>>> the router cares about not being able to send a response or not
> >> >>>>>>>>>> though, but it might.
> >> >>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> You could add the following to your dispatch router conf file
> >> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable
> trace
> >> >>>>>>>>>
> >> >>>>>>>> logging)
> >> >>>>>>
> >> >>>>>>>
> >> >>>>>>>>> log {
> >> >>>>>>>>> module: DEFAULT
> >> >>>>>>>>> enable: trace+
> >> >>>>>>>>> output: /path/to/log/qdrouterd.log
> >> >>>>>>>>> }
> >> >>>>>>>>>
> >> >>>>>>>>> When you run your management request, you will see proton
> frame
> >> >>>>>>>>> trace
> >> >>>>>>>>> and
> >> >>>>>>>>> you will see additional logging out of the dispatch Python
> agent
> >> -
> >> >>>>>>>>> something like the following -
> >> >>>>>>>>>
> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
> >> >>>>>>>>> Message(address=None,
> >> >>>>>>>>> properties={'operation': 'CREATE', 'type':
> >> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
> >> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
> >> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
> >> >>>>>>>>>
> >> >>>>>>>> 'rabih.connector'},
> >> >>>>>>
> >> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
> >> >>>>>>>>> correlation_id=1L)
> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
> >> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
> >> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
> >> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True,
> cost=1,
> >> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
> >> 5673:rabih.connector,
> >> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
> >> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
> >> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.
> connector,
> >> >>>>>>>>> verifyHostName=True)
> >> >>>>>>>>>
> >> >>>>>>>>> The Python management agent will not process your request if
> >> there
> >> >>>>>>>>> is
> >> >>>>>>>>>
> >> >>>>>>>> no
> >> >>>>>>
> >> >>>>>>> reply_to as seen here -
> >> >>>>>>>>>
> >> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
> >> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
> >> because
> >> >>>>>>>> there
> >> >>>>>>>> is
> >> >>>>>>>> a reply-to doesn't mean that the sender will be around to
> actually
> >> >>>>>>>> hear
> >> >>>>>>>> the
> >> >>>>>>>> reply, so it seems a bit arbitrary to say that because we
> *know*
> >> the
> >> >>>>>>>> sender
> >> >>>>>>>> won't learn of the outcome that we won't do anything... The
> spec
> >> >>>>>>>> draft
> >> >>>>>>>> doesn't currently say anything about this (obviously it should
> >> do),
> >> >>>>>>>> but
> >> >>>>>>>>
> >> >>>>>>> my
> >> >>>>>>
> >> >>>>>>> expectation would certainly be that a request would be processed
> >> even
> >> >>>>>>>> if
> >> >>>>>>>> the replyTo address was not present (or ended up not routing
> >> >>>>>>>> anywhere).
> >> >>>>>>>> This is also how the Qpid Broker for Java implements this case.
> >> >>>>>>>>
> >> >>>>>>>> -- Rob
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> Thanks.
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>> Robbie
> >> >>>>>>>>>>
> >> >>>>>>>>>> ------------------------------------------------------------
> >> >>>>>>>>>>
> >> >>>>>>>>> ---------
> >> >>>>>>
> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>> ------------------------------------------------------------
> >> >>>>>>>>> ---------
> >> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> ------------------------------------------------------------
> >> ---------
> >> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> ------------------------------------------------------------
> >> ---------
> >> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>> ------------------------------------------------------------
> ---------
> >> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>>
> >> >>>>
> >> >>> ------------------------------------------------------------
> ---------
> >> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >>> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>>
> >> >>>
> >> >> ------------------------------------------------------------
> ---------
> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Robbie Gemmell <ro...@gmail.com>.
On 15 February 2017 at 14:15, Adel Boutros <Ad...@live.com> wrote:
> Hello guys,
>
>
> Based on the discussion, we are currently writing a Java API based on JMS to configure the dispatch router. I have so far managed to do the following:
>
> * Create, Read, Delete addresses
>
> * Create, Read, Delete connectors
>
>
> Config:
>
> Dispatch Router 0.7.0
>
> JMS 0.11.1
>
>
> And I have noticed some problems and differences:
>
>
> 1) It seems some calls return ObjectMessage and some TextMessage (This is on the side of the consumer in the replyTo)
>
> For example, creating twice the same queue will fail but the second call will return a JmsTextMessage with an empty body and status code 400
>
The client treats messages with an amqp-value sectioning containing
null/nothing as a TextMessage with null value if they arent annotated
to say otherwise, I'd guess thats where that comes from.
>
> 2) Returned statusCode differs between Connector and Address
>
> Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
>
>
> * Connector operations return java.lang.Long
> * Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
>
The router is presumably sending different values back for the
different operations here, a long and a uint. The router should
perhaps be consistent, and the client should perhaps not be returning
the uint object either way.
The last draft of the management spec seems to say the status code
should be 'integer', im not clear if it means int (not uint)
specifically, or just any integral type value.
>
> 3) Create connector twice makes dispatch router crash. I don't have the issue when creating addresses.
> On the second create call, JMS client receives a normal reply containing a statusCode of an exception. After I close the connection to the dispatch router via JMS (connection.close), I have the below crash
>
> (gdb) where
> #0 0x00007f27194448a5 in raise () from /lib64/libc.so.6
> #1 0x00007f2719446085 in abort () from /lib64/libc.so.6
> #2 0x00007f27194827b7 in __libc_message () from /lib64/libc.so.6
> #3 0x00007f27194880e6 in malloc_printerr () from /lib64/libc.so.6
> #4 0x00007f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf expression opcode 0xf3
> ) at /qpid-dispatch-0.7.0/src/hash.c:320
> #5 0x00007f271a42247d in qdr_route_check_id_for_deletion_CT (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
> ) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
> #6 0x00007f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30, action=Unhandled dwarf expression opcode 0xf3
> ) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
> #7 0x00007f271a423f30 in router_core_thread (arg=0x13d2d30) at /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
> #8 0x00007f2719f8c851 in start_thread () from /lib64/libpthread.so.0
> #9 0x00007f27194fa90d in clone () from /lib64/libc.so.6
>
>
> Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE: org.apache.qpid.dispatch.connector: Duplicate value 'connector/127.0.0.1:5915:dispatch_management_connector_test' for unique attribute 'identity'
> *** glibc detected *** /Dispatch/sbin/qdrouterd: double free or corruption (fasttop): 0x00007f2708033f10 ***
> ======= Backtrace: =========
> /lib64/libc.so.6(+0x760e6)[0x7f27194880e6]
> /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch.so(qd_hash_remove_by_handle+0x29)[0x7f271a40f109]
> /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch.so(+0x3547d)[0x7f271a42247d]
> /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch.so(+0x318d3)[0x7f271a41e8d3]
> /target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch.so(router_core_thread+0x230)[0x7f271a423f30]
> /lib64/libpthread.so.0(+0x7851)[0x7f2719f8c851]
> /lib64/libc.so.6(clone+0x6d)[0x7f27194fa90d]
> ======= Memory map: ========
> 00400000-00403000 r-xp 00000000 fd:01 7735642 /Dispatch/sbin/qdrouterd
> 00603000-00604000 rw-p 00003000 fd:01 7735642 /Dispatch/sbin/qdrouterd
> 01113000-01458000 rw-p 00000000 00:00 0 [heap]
> 7f26f8000000-7f26f805c000 rw-p 00000000 00:00 0
> 7f26f805c000-7f26fc000000 ---p 00000000 00:00 0
> 7f26fc000000-7f26fc043000 rw-p 00000000 00:00 0
> 7f26fc043000-7f2700000000 ---p 00000000 00:00 0
> 7f2700000000-7f2700085000 rw-p 00000000 00:00 0
> 7f2700085000-7f2704000000 ---p 00000000 00:00 0
> 7f27073e9000-7f27073ff000 r-xp 00000000 fd:00 524293 /lib64/libgcc_s-4.4.7-20120601.so.1
> 7f27073ff000-7f27075fe000 ---p 00016000 fd:00 524293 /lib64/libgcc_s-4.4.7-20120601.so.1
> 7f27075fe000-7f27075ff000 rw-p 00015000 fd:00 524293 /lib64/libgcc_s-4.4.7-20120601.so.1
> 7f27075ff000-7f2707600000 ---p 00000000 00:00 0
> 7f2707600000-7f2708000000 rw-p 00000000 00:00 0
> 7f2708000000-7f270805a000 rw-p 00000000 00:00 0
> 7f270805a000-7f270c000000 ---p 00000000 00:00 0
> 7f270c04a000-7f270c04f000 r-xp 00000000 fd:00 524322 /lib64/libnss_dns-2.12.so
> 7f270c04f000-7f270c24e000 ---p 00005000 fd:00 524322 /lib64/libnss_dns-2.12.so
> 7f270c24e000-7f270c24f000 r--p 00004000 fd:00 524322 /lib64/libnss_dns-2.12.so
> 7f270c24f000-7f270c250000 rw-p 00005000 fd:00 524322 /lib64/libnss_dns-2.12.so
> 7f270c250000-7f270c251000 ---p 00000000 00:00 0
> 7f270c251000-7f270cc51000 rw-p 00000000 00:00 0
> 7f270cc51000-7f270cc52000 ---p 00000000 00:00 0
> 7f270cc52000-7f270d652000 rw-p 00000000 00:00 0
> 7f270d652000-7f270d65e000 r-xp 00000000 fd:00 524324 /lib64/libnss_files-2.12.so
> 7f270d65e000-7f270d85e000 ---p 0000c000 fd:00 524324 /lib64/libnss_files-2.12.so
> 7f270d85e000-7f270d85f000 r--p 0000c000 fd:00 524324 /lib64/libnss_files-2.12.so
> 7f270d85f000-7f270d860000 rw-p 0000d000 fd:00 524324 /lib64/libnss_files-2.12.so
> 7f270d86a000-7f270d86b000 ---p 00000000 00:00 0
> 7f270d86b000-7f270e3ac000 rw-p 00000000 00:00 0
> 7f270e3ac000-7f270e3b1000 r-xp 00000000 00:16 4090944 /python278/lib/python2.7/lib-dynload/select.so
> 7f270e3b1000-7f270e5b0000 ---p 00005000 00:16 4090944 /python278/lib/python2.7/lib-dynload/select.so
> 7f270e5b0000-7f270e5b2000 rw-p 00004000 00:16 4090944 /python278/lib/python2.7/lib-dynload/select.so
> 7f270e5b2000-7f270e5b6000 r-xp 00000000 00:16 5568743 /python278/lib/python2.7/lib-dynload/_lsprof.so
> 7f270e5b6000-7f270e7b5000 ---p 00004000 00:16 5568743 /python278/lib/python2.7/lib-dynload/_lsprof.so
> 7f270e7b5000-7f270e7b6000 rw-p 00003000 00:16 5568743 /python278/lib/python2.7/lib-dynload/_lsprof.so
> 7f270e7b6000-7f270e8b7000 rw-p 00000000 00:00 0
> 7f270e8b7000-7f270e8bc000 r-xp 00000000 00:16 6394000 /python278/lib/python2.7/lib-dynload/strop.so
> 7f270e8bc000-7f270eabb000 ---p 00005000 00:16 6394000 /python278/lib/python2.7/lib-dynload/strop.so
> 7f270eabb000-7f270eabd000 rw-p 00004000 00:16 6394000 /python278/lib/python2.7/lib-dynload/strop.so
> 7f270eabd000-7f270eafd000 rw-p 00000000 00:00 0
> 7f270eafd000-7f270eb00000 r-xp 00000000 00:16 5568749 /python278/lib/python2.7/lib-dynload/fcntl.so
> 7f270eb00000-7f270ecff000 ---p 00003000 00:16 5568749 /python278/lib/python2.7/lib-dynload/fcntl.so
> 7f270ecff000-7f270ed01000 rw-p 00002000 00:16 5568749 /python278/lib/python2.7/lib-dynload/fcntl.so
> 7f270ed01000-7f270ed04000 r-xp 00000000 00:16 5568739 /python278/lib/python2.7/lib-dynload/_random.so
> 7f270ed04000-7f270ef03000 ---p 00003000 00:16 5568739 /python278/lib/python2.7/lib-dynload/_random.so
> 7f270ef03000-7f270ef04000 rw-p 00002000 00:16 5568739 /python278/lib/python2.7/lib-dynload/_random.so
> 4272 Aborted (core dumped)
>
>
> Regards,
> Adel
>
>
> ________________________________
> From: Rob Godfrey <ro...@gmail.com>
> Sent: Monday, February 6, 2017 7:09 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com> wrote:
>> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
>> >
>> >> It seems odd that the client creates a _sender_ to the temporary queue
>> >> that it will never send messages _to_ but will receive messages _from_.
>> >>
>> >>
>> > This is because JMS semantics require the temporary node to have a
>> lifetime
>> > scoped to the session (not a link), so the JMS client has to create a
>> > synthetic link which it uses simply to manage the lifetime of the dynamic
>> > node. In order to not cause unintentional assigning of messages to a
>> link
>> > that will never actually be used for consumption, a sending link is used.
>> > Note that in general JMS would expect that you should be able to send to
>> a
>> > temporary queue created in this way (since the point of temporary queues
>> is
>> > to use as a reply to)
>> >
>>
>> Not really important here, but the lifetime is scoped to the
>> Connection, not Session (agghhh JMS... :P)
>>
>
> That's what I thought I was typing... obviously my fingers were not
> cooperating with my brain at that point :-)
>
> -- Rob
>
>
>>
>> >
>> >> Anyway, when the client creates a receiver with a dynamic source (and no
>> >> dynamic-node-properties), the router will accept the link and assign a
>> >> temporary address as the source. This is only useful in this use case
>> if
>> >> the broker has a way of knowing that the temporary address is reachable
>> via
>> >> the router network.
>> >>
>> >> There is a way to route dynamic termini to a broker. If an
>> >> x-opt-qd.address property is included in the dynamic-node-properties,
>> this
>> >> address will be used to route the attach to the broker. I've never
>> tested
>> >> this with a dynamic target in a sender. It might not work.
>> >
>> >
>> > And this really isn't something you'd be expecting a generic client (like
>> > the JMS client) to know :-)
>> >
>> > -- Rob
>> >
>> >
>> >>
>> >>
>> >> -Ted
>> >>
>> >>
>> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
>> >>
>> >>> I've had a look at this. It would seem that Dispatch doesn't like what
>> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
>> >>> very nice way, and the client then doesnt notice that things have gone
>> >>> south in a somewhat unexpected way.
>> >>>
>> >>> The client opens a sending link with 'dynamic' target in order to
>> >>> create a dynamic node for use as a TemporaryQueue address/destination
>> >>> object, which specific consumers/producers are then created against by
>> >>> the application. Dispatch doesn't seem to like that but erroneously
>> >>> attaches the link 'successfully', though doesnt set a target address
>> >>> as is expected. The client then doesnt notice this happened (its
>> >>> checking for the link being refused, which it wasn't), allowing the
>> >>> application to proceed as far as creating consumers/procuers using the
>> >>> TemporaryQueue object, with creation of the e.g Consumer then failing
>> >>> since the attach doesnt contain the needed information and leads to
>> >>> Dispatch detaching it with the error (though it again doesnt actually
>> >>> indicate its refusing the link during the attach response, as it
>> >>> probably should have in this case).
>> >>>
>> >>> Making the client detect the current failure and having it throw an
>> >>> aexception from createTemporaryQueue is simple enough.
>> >>>
>> >>> Hacking the client to use a dynamic recieving link instead, an address
>> >>> was returned by Dispatch in the attach response as expected, however a
>> >>> consumer on the resulting TemporaryQueue object using this address
>> >>> still didnt get the message I sent to the same place. If I also gave
>> >>> some credit on the link backing the TemporaryQeueue object itself then
>> >>> that link gets sent the message by Dispatch, though this of no use for
>> >>> the JMS client.
>> >>>
>> >>> Needs some more investigation, and I'll need to discuss with some
>> >>> folks more familiar with Dispatch.
>> >>>
>> >>> Robbie
>> >>>
>> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
>> wrote:
>> >>>
>> >>>> Hello Robbie,
>> >>>>
>> >>>>
>> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the reply
>> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS Client.
>> >>>>
>> >>>>
>> >>>> PS: As Rabih stated before, we are using the same connection and same
>> >>>> session to create the JMSProducer for the request and the
>> JMSConsumer for
>> >>>> the reply.
>> >>>>
>> >>>>
>> >>>> Exception
>> >>>> -------------------
>> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed due
>> to
>> >>>> an unrecoverable error.
>> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
>> >>>> eConsumer.java:330)
>> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
>> >>>> sumer.java:196)
>> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
>> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> >>>> ssorImpl.java:62)
>> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> >>>> thodAccessorImpl.java:43)
>> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
>> >>>> at com.intellij.rt.execution.application.AppMain.main(
>> AppMain.java:147)
>> >>>> Caused by: javax.jms.JMSException: No route to the destination node
>> >>>> [condition = qd:no-route-to-dest]
>> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>> >>>> tion(AmqpSupport.java:150)
>> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>> >>>> tion(AmqpSupport.java:105)
>> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
>> >>>> elyClosed(AmqpAbstractResource.java:147)
>> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
>> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
>> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
>> >>>> s(AmqpProvider.java:795)
>> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
>> >>>> mqpProvider.java:90)
>> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
>> >>>> ovider.java:699)
>> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
>> >>>> Executors.java:511)
>> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
>> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> >>>> Executor.java:1142)
>> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> >>>> lExecutor.java:617)
>> >>>> at java.lang.Thread.run(Thread.java:745)
>> >>>>
>> >>>>
>> >>>> -------------------
>> >>>> Dispatch Router (PN_TRACE_FRM=1)
>> >>>> -------------------
>> >>>>
>> >>>> [832220]: <- SASL
>> >>>> [832220]: -> SASL
>> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
>> >>>> MBOL[:ANONYMOUS]]
>> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
>> >>>> initial-response=b"", hostname="host-name"]
>> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
>> >>>> [832220]: <- AMQP
>> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
>> a334-44c3-954a-2dd910161411:1",
>> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
>> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
>> >>>> L[:"sole-connection-for-container"], properties={:product="QpidJMS",
>> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
>> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
>> >>>> [832220]: -> AMQP
>> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
>> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
>> >>>> offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-
>> dispatch-router",
>> >>>> :version="0.7.0"}]
>> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>> >>>> outgoing-window=2147483647, handle-max=65535]
>> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
>> >>>> incoming-window=61, outgoing-window=2147483647]
>> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>> >>>> outgoing-window=2147483647, handle-max=65535]
>> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
>> >>>> incoming-window=61, outgoing-window=2147483647]
>> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
>> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
>> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
>> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]],
>> >>>> target=@target(41) [address="$management", durable=0,
>> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
>> >>>> initial-delivery-count=0]
>> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
>> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
>> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list",
>> >>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
>> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
>> queue]],
>> >>>> initial-delivery-count=0, max-message-size=0]
>> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>> delivery-count=0,
>> >>>> link-credit=250, drain=false]
>> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
>> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
>> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
>> [],
>> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
>> timeout=0,
>> >>>> dynamic=true, dynamic-node-properties={:"lif
>> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
>> temporary-queue"]],
>> >>>> incomplete-unsettled=false, initial-delivery-count=0]
>> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
>> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
>> role=true,
>> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
>> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
>> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
>> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []},
>> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
>> initial-delivery-count=0,
>> >>>> max-message-size=0]
>> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>> delivery-count=0,
>> >>>> link-credit=250, drain=false]
>> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
>> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=true,
>> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [durable=0,
>> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
>> >>>> default-outcome=@modified(39) [delivery-failed=true],
>> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
>> >>>> :"amqp:released:list", :"amqp:modified:list"],
>> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41) []]
>> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
>> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=false,
>> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
>> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0,
>> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
>> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
>> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
>> >>>> destination node"]]
>> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
>> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
>> delivery-tag=b"0",
>> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
>> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
>> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
>> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
>> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
>> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
>> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
>> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
>> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
>> >>>> x04addr\xa1\x0dbrokerMachine"
>> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
>> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
>> delivery-count=1,
>> >>>> link-credit=250, drain=false]
>> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
>> >>>> settled=true, state=@accepted(36) []]
>> >>>> [832220]:0 <- @close(24) []
>> >>>> [832220]: <- EOS
>> >>>> [832220]:0 -> @close(24) []
>> >>>> [832220]: -> EOS
>> >>>> Closed x.x.x.x:8961
>> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
>> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
>> >>>>
>> >>>> ------------------
>> >>>> JMS Client (PN_TRACE_FRM=1)
>> >>>> ------------------
>> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
>> 4a22-9b22-69d27a017a83:1',
>> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
>> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
>> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
>> connection-for-container],
>> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM: 1.8.0_111,
>> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
>> >>>> [1244186219:0] <- Open{ containerId='router.10200', hostname='null',
>> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
>> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
>> ANONYMOUS-RELAY],
>> >>>> desiredCapabilities=null, properties={product=qpid-dispatch-router,
>> >>>> version=0.7.0}}
>> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
>> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
>> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
>> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
>> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
>> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
>> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
>> 3293ffc57168:1:1:1',
>> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
>> amqp:rejected:list],
>> >>>> capabilities=null}, target=Target{address='$management',
>> durable=NONE,
>> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> maxMessageSize=null,
>> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
>> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
>> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
>> 3293ffc57168:1:1:1',
>> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
>> amqp:rejected:list],
>> >>>> capabilities=null}, target=Target{address='$management',
>> durable=NONE,
>> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>> >>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
>> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
>> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>> deliveryCount=0,
>> >>>> linkCredit=250, available=null, drain=false, echo=false,
>> properties=null}
>> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
>> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>> >>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>> outcomes=null,
>> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>> >>>> capabilities=[temporary-queue]}, unsettled=null,
>> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
>> maxMessageSize=null,
>> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
>> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>> >>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>> outcomes=null,
>> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>> >>>> capabilities=[temporary-queue]}, unsettled=null,
>> >>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
>> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
>> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>> deliveryCount=0,
>> >>>> linkCredit=250, available=null, drain=false, echo=false,
>> properties=null}
>> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
>> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>> >>>> source=Source{address='null', durable=NONE, expiryPolicy=LINK_DETACH,
>> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
>> deliveryFailed=true,
>> >>>> undeliverableHere=null, messageAnnotations=null},
>> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list,
>> >>>> amqp:modified:list], capabilities=[temporary-queue]},
>> >>>> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
>> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> capabilities=null},
>> >>>> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
>> >>>> maxMessageSize=null, offeredCapabilities=null,
>> desiredCapabilities=null,
>> >>>> properties=null}
>> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
>> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>> >>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>> >>>> distributionMode=null, filter=null, defaultOutcome=null,
>> outcomes=null,
>> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
>> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
>> >>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
>> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
>> >>>> error=Error{condition=qd:no-route-to-dest, description='No route to
>> the
>> >>>> destination node', info=null}}
>> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
>> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
>> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
>> state=null,
>> >>>> resume=false, aborted=false, batchable=false} (312)
>> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
>> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
>> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@
>> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
>> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
>> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
>> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
>> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
>> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
>> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
>> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
>> deliveryCount=1,
>> >>>> linkCredit=250, available=null, drain=false, echo=false,
>> properties=null}
>> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
>> >>>> settled=true, state=Accepted{}, batchable=false}
>> >>>> [1244186219:0] -> Close{error=null}
>> >>>> [1244186219:0] <- Close{error=null}
>> >>>>
>> >>>> Regards,
>> >>>>
>> >>>> Adel
>> >>>>
>> >>>> ________________________________
>> >>>> From: Robbie Gemmell <ro...@gmail.com>
>> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
>> >>>> To: users@qpid.apache.org
>> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>> >>>>
>> >>>> That looks fine at first glance. Its possible there is an issue in
>> >>>> there needing looked it. I am travelling this week so may not get to
>> >>>> look until afterwards, but will try to give things a look at. If you
>> >>>> could give more detail on the exception and maybe a protocol trace
>> >>>> that might be useful.
>> >>>>
>> >>>> Robbie
>> >>>>
>> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
>> >>>>
>> >>>>> Hello Robbie,
>> >>>>>
>> >>>>> Thanks for you for your answer.
>> >>>>> I will try the solutions you proposed.
>> >>>>>
>> >>>>> I need just need one clarification. Concerning the Jms, I already
>> tried
>> >>>>> to
>> >>>>> use a temporary queue but it didn't work. May be i am using it wrong.
>> >>>>> Here
>> >>>>> is what i did:
>> >>>>>
>> >>>>> ...
>> >>>>> Session session = connection.createSession(false,
>> >>>>> Session.AUTO_ACKNOWLEDGE);
>> >>>>> Queue queue = session.createQueue("$management");
>> >>>>> MessageProducer producer = session.createProducer(queue);
>> >>>>>
>> >>>>> Queue tempDest = session.createTemporaryQueue();
>> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDest);
>> >>>>> connection.start();
>> >>>>>
>> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
>> >>>>> objectMessage.setJMSReplyTo(tempDest);
>> >>>>> //fill the rest of the parameters ...
>> >>>>> producer.send(objectMessage);
>> >>>>> ObjectMessage replyMessage = (ObjectMessage)
>> >>>>> responseConsumer.receive(1000);
>> >>>>> ...
>> >>>>>
>> >>>>> I was getting an exception on the .receive() from the dispatch router
>> >>>>> saying that the reply-to address is bad...
>> >>>>> Should i create the temporary queue and the consumer from a different
>> >>>>> session then the producer?
>> >>>>>
>> >>>>> Best regards,
>> >>>>> Rabih
>> >>>>>
>> >>>>>
>> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
>> >>>>> robbie.gemmell@gmail.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>> The session.createTemporaryQueue(); method is how JMS creates
>> >>>>>> temporary destinations for use in reply-to scenarios. The dispatch
>> >>>>>> tools will be doing essentially the same thing under the covers for
>> >>>>>> theirs.
>> >>>>>>
>> >>>>>> Both work by creating a 'dynamic' link attachment, with the server
>> >>>>>> returning an address for the dynamic attach to the client. One key
>> >>>>>> difference is with JMS you create the temporary destination (for
>> which
>> >>>>>> the client uses a dynamic sender link to create), then separately
>> >>>>>> create a receiver using it (and in turn the address associated with
>> >>>>>> it), whereas non-JMS client/tools will typically just create a
>> single
>> >>>>>> dynamic receiver link and use its address for the reply-to.
>> >>>>>>
>> >>>>>> For proton-j, there aren't any examples for this, but you you
>> >>>>>> essentially would change the link opening to not specify an address,
>> >>>>>> and instead set the source(for a receiver) or target (for a sender)
>> to
>> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
>> remoteTarget
>> >>>>>> once the link had been reemotely attached, and get its
>> >>>>>> (server-generated) address, then use this as your reply-to.
>> >>>>>>
>> >>>>>> Robbie
>> >>>>>>
>> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
>> wrote:
>> >>>>>>
>> >>>>>>> Hello,
>> >>>>>>>
>> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like you
>> >>>>>>> suggested, it worked.
>> >>>>>>> But I cheated a little to make it work because I did not find a
>> way in
>> >>>>>>>
>> >>>>>> JMS
>> >>>>>>
>> >>>>>>> to create a local queue. So I created a queue on the qpid-dispatch
>> and
>> >>>>>>>
>> >>>>>> read
>> >>>>>>
>> >>>>>>> the result from it. You can check the attached code.
>> >>>>>>>
>> >>>>>>> Is there any way using qpid-jms to create a local queue on the
>> client
>> >>>>>>>
>> >>>>>> side
>> >>>>>>
>> >>>>>>> to serve as a reply to address?
>> >>>>>>>
>> >>>>>>> For the proton-j test, I have the same question as above. I saw
>> that
>> >>>>>>> it
>> >>>>>>>
>> >>>>>> can
>> >>>>>>
>> >>>>>>> be done with the C++ API. Are there any examples for proton-j or
>> >>>>>>>
>> >>>>>> something
>> >>>>>>
>> >>>>>>> that can help me?
>> >>>>>>>
>> >>>>>>> I saw may be in proton we don't need a local queue, may be we can
>> get
>> >>>>>>> the
>> >>>>>>> address of the consumer directly and pass it in reply-to field. Is
>> it
>> >>>>>>> correct?
>> >>>>>>>
>> >>>>>>> Thanks,
>> >>>>>>> Rabih
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
>> >>>>>>> rob.j.godfrey@gmail.com>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com>
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> ----- Original Message -----
>> >>>>>>>>>
>> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
>> >>>>>>>>>> To: users@qpid.apache.org
>> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
>> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid
>> Jms
>> >>>>>>>>>>
>> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you
>> told
>> >>>>>>>>>>>>
>> >>>>>>>>>>> me
>> >>>>>>
>> >>>>>>> Robbie and it worked.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> But like the proton-j case, the connector is not being
>> created on
>> >>>>>>>>>>>> the
>> >>>>>>>>>>>> Qpid-dispatch side.
>> >>>>>>>>>>>> I attached the amqp communication into this mail.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> The last frame in that file is incomplete (the previous error
>> >>>>>>>>>>>
>> >>>>>>>>>> regarding the
>> >>>>>>>>>
>> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
>> frame
>> >>>>>>>>>>>
>> >>>>>>>>>> is
>> >>>>>>
>> >>>>>>> likely
>> >>>>>>>>>
>> >>>>>>>>>> the response which would indicate the success or otherwise of
>> the
>> >>>>>>>>>>>
>> >>>>>>>>>> frame. Is
>> >>>>>>>>>
>> >>>>>>>>>> there anything logged by the router?
>> >>>>>>>>>>>
>> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
>> simpler
>> >>>>>>>>>>> for
>> >>>>>>>>>>>
>> >>>>>>>>>> this
>> >>>>>>>>>
>> >>>>>>>>>> sort of thing in my view.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more helpful.
>> >>>>>>>>>> You
>> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
>> since
>> >>>>>>>>>> it
>> >>>>>>>>>> uses proton-j.
>> >>>>>>>>>>
>> >>>>>>>>>> One key difference from the qdmanage case is you are not
>> setting a
>> >>>>>>>>>> reply-to value or correlation-id to use along with it. I don't
>> know
>> >>>>>>>>>>
>> >>>>>>>>> if
>> >>>>>>
>> >>>>>>> the router cares about not being able to send a response or not
>> >>>>>>>>>> though, but it might.
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> You could add the following to your dispatch router conf file
>> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable trace
>> >>>>>>>>>
>> >>>>>>>> logging)
>> >>>>>>
>> >>>>>>>
>> >>>>>>>>> log {
>> >>>>>>>>> module: DEFAULT
>> >>>>>>>>> enable: trace+
>> >>>>>>>>> output: /path/to/log/qdrouterd.log
>> >>>>>>>>> }
>> >>>>>>>>>
>> >>>>>>>>> When you run your management request, you will see proton frame
>> >>>>>>>>> trace
>> >>>>>>>>> and
>> >>>>>>>>> you will see additional logging out of the dispatch Python agent
>> -
>> >>>>>>>>> something like the following -
>> >>>>>>>>>
>> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>> >>>>>>>>> Message(address=None,
>> >>>>>>>>> properties={'operation': 'CREATE', 'type':
>> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
>> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
>> >>>>>>>>>
>> >>>>>>>> 'rabih.connector'},
>> >>>>>>
>> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>> >>>>>>>>> correlation_id=1L)
>> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
>> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
>> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
>> 5673:rabih.connector,
>> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
>> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
>> >>>>>>>>> verifyHostName=True)
>> >>>>>>>>>
>> >>>>>>>>> The Python management agent will not process your request if
>> there
>> >>>>>>>>> is
>> >>>>>>>>>
>> >>>>>>>> no
>> >>>>>>
>> >>>>>>> reply_to as seen here -
>> >>>>>>>>>
>> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
>> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
>> because
>> >>>>>>>> there
>> >>>>>>>> is
>> >>>>>>>> a reply-to doesn't mean that the sender will be around to actually
>> >>>>>>>> hear
>> >>>>>>>> the
>> >>>>>>>> reply, so it seems a bit arbitrary to say that because we *know*
>> the
>> >>>>>>>> sender
>> >>>>>>>> won't learn of the outcome that we won't do anything... The spec
>> >>>>>>>> draft
>> >>>>>>>> doesn't currently say anything about this (obviously it should
>> do),
>> >>>>>>>> but
>> >>>>>>>>
>> >>>>>>> my
>> >>>>>>
>> >>>>>>> expectation would certainly be that a request would be processed
>> even
>> >>>>>>>> if
>> >>>>>>>> the replyTo address was not present (or ended up not routing
>> >>>>>>>> anywhere).
>> >>>>>>>> This is also how the Qpid Broker for Java implements this case.
>> >>>>>>>>
>> >>>>>>>> -- Rob
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Thanks.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> Robbie
>> >>>>>>>>>>
>> >>>>>>>>>> ------------------------------------------------------------
>> >>>>>>>>>>
>> >>>>>>>>> ---------
>> >>>>>>
>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>> ------------------------------------------------------------
>> >>>>>>>>> ---------
>> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> ------------------------------------------------------------
>> ---------
>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >>>>>>>
>> >>>>>>
>> >>>>>> ------------------------------------------------------------
>> ---------
>> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >>>> For additional commands, e-mail: users-help@qpid.apache.org
>> >>>>
>> >>>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >>> For additional commands, e-mail: users-help@qpid.apache.org
>> >>>
>> >>>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> For additional commands, e-mail: users-help@qpid.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Adel Boutros <Ad...@live.com>.
Hello guys,
Based on the discussion, we are currently writing a Java API based on JMS to configure the dispatch router. I have so far managed to do the following:
* Create, Read, Delete addresses
* Create, Read, Delete connectors
Config:
Dispatch Router 0.7.0
JMS 0.11.1
And I have noticed some problems and differences:
1) It seems some calls return ObjectMessage and some TextMessage (This is on the side of the consumer in the replyTo)
For example, creating twice the same queue will fail but the second call will return a JmsTextMessage with an empty body and status code 400
2) Returned statusCode differs between Connector and Address
Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
* Connector operations return java.lang.Long
* Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
3) Create connector twice makes dispatch router crash. I don't have the issue when creating addresses.
On the second create call, JMS client receives a normal reply containing a statusCode of an exception. After I close the connection to the dispatch router via JMS (connection.close), I have the below crash
(gdb) where
#0 0x00007f27194448a5 in raise () from /lib64/libc.so.6
#1 0x00007f2719446085 in abort () from /lib64/libc.so.6
#2 0x00007f27194827b7 in __libc_message () from /lib64/libc.so.6
#3 0x00007f27194880e6 in malloc_printerr () from /lib64/libc.so.6
#4 0x00007f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf expression opcode 0xf3
) at /qpid-dispatch-0.7.0/src/hash.c:320
#5 0x00007f271a42247d in qdr_route_check_id_for_deletion_CT (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
#6 0x00007f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30, action=Unhandled dwarf expression opcode 0xf3
) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
#7 0x00007f271a423f30 in router_core_thread (arg=0x13d2d30) at /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
#8 0x00007f2719f8c851 in start_thread () from /lib64/libpthread.so.0
#9 0x00007f27194fa90d in clone () from /lib64/libc.so.6
Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE: org.apache.qpid.dispatch.connector: Duplicate value 'connector/127.0.0.1:5915:dispatch_management_connector_test' for unique attribute 'identity'
*** glibc detected *** /Dispatch/sbin/qdrouterd: double free or corruption (fasttop): 0x00007f2708033f10 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x760e6)[0x7f27194880e6]
/target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch.so(qd_hash_remove_by_handle+0x29)[0x7f271a40f109]
/target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch.so(+0x3547d)[0x7f271a42247d]
/target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch.so(+0x318d3)[0x7f271a41e8d3]
/target/qpid-dispatch-rel/lib/qpid-dispatch/libqpid-dispatch.so(router_core_thread+0x230)[0x7f271a423f30]
/lib64/libpthread.so.0(+0x7851)[0x7f2719f8c851]
/lib64/libc.so.6(clone+0x6d)[0x7f27194fa90d]
======= Memory map: ========
00400000-00403000 r-xp 00000000 fd:01 7735642 /Dispatch/sbin/qdrouterd
00603000-00604000 rw-p 00003000 fd:01 7735642 /Dispatch/sbin/qdrouterd
01113000-01458000 rw-p 00000000 00:00 0 [heap]
7f26f8000000-7f26f805c000 rw-p 00000000 00:00 0
7f26f805c000-7f26fc000000 ---p 00000000 00:00 0
7f26fc000000-7f26fc043000 rw-p 00000000 00:00 0
7f26fc043000-7f2700000000 ---p 00000000 00:00 0
7f2700000000-7f2700085000 rw-p 00000000 00:00 0
7f2700085000-7f2704000000 ---p 00000000 00:00 0
7f27073e9000-7f27073ff000 r-xp 00000000 fd:00 524293 /lib64/libgcc_s-4.4.7-20120601.so.1
7f27073ff000-7f27075fe000 ---p 00016000 fd:00 524293 /lib64/libgcc_s-4.4.7-20120601.so.1
7f27075fe000-7f27075ff000 rw-p 00015000 fd:00 524293 /lib64/libgcc_s-4.4.7-20120601.so.1
7f27075ff000-7f2707600000 ---p 00000000 00:00 0
7f2707600000-7f2708000000 rw-p 00000000 00:00 0
7f2708000000-7f270805a000 rw-p 00000000 00:00 0
7f270805a000-7f270c000000 ---p 00000000 00:00 0
7f270c04a000-7f270c04f000 r-xp 00000000 fd:00 524322 /lib64/libnss_dns-2.12.so
7f270c04f000-7f270c24e000 ---p 00005000 fd:00 524322 /lib64/libnss_dns-2.12.so
7f270c24e000-7f270c24f000 r--p 00004000 fd:00 524322 /lib64/libnss_dns-2.12.so
7f270c24f000-7f270c250000 rw-p 00005000 fd:00 524322 /lib64/libnss_dns-2.12.so
7f270c250000-7f270c251000 ---p 00000000 00:00 0
7f270c251000-7f270cc51000 rw-p 00000000 00:00 0
7f270cc51000-7f270cc52000 ---p 00000000 00:00 0
7f270cc52000-7f270d652000 rw-p 00000000 00:00 0
7f270d652000-7f270d65e000 r-xp 00000000 fd:00 524324 /lib64/libnss_files-2.12.so
7f270d65e000-7f270d85e000 ---p 0000c000 fd:00 524324 /lib64/libnss_files-2.12.so
7f270d85e000-7f270d85f000 r--p 0000c000 fd:00 524324 /lib64/libnss_files-2.12.so
7f270d85f000-7f270d860000 rw-p 0000d000 fd:00 524324 /lib64/libnss_files-2.12.so
7f270d86a000-7f270d86b000 ---p 00000000 00:00 0
7f270d86b000-7f270e3ac000 rw-p 00000000 00:00 0
7f270e3ac000-7f270e3b1000 r-xp 00000000 00:16 4090944 /python278/lib/python2.7/lib-dynload/select.so
7f270e3b1000-7f270e5b0000 ---p 00005000 00:16 4090944 /python278/lib/python2.7/lib-dynload/select.so
7f270e5b0000-7f270e5b2000 rw-p 00004000 00:16 4090944 /python278/lib/python2.7/lib-dynload/select.so
7f270e5b2000-7f270e5b6000 r-xp 00000000 00:16 5568743 /python278/lib/python2.7/lib-dynload/_lsprof.so
7f270e5b6000-7f270e7b5000 ---p 00004000 00:16 5568743 /python278/lib/python2.7/lib-dynload/_lsprof.so
7f270e7b5000-7f270e7b6000 rw-p 00003000 00:16 5568743 /python278/lib/python2.7/lib-dynload/_lsprof.so
7f270e7b6000-7f270e8b7000 rw-p 00000000 00:00 0
7f270e8b7000-7f270e8bc000 r-xp 00000000 00:16 6394000 /python278/lib/python2.7/lib-dynload/strop.so
7f270e8bc000-7f270eabb000 ---p 00005000 00:16 6394000 /python278/lib/python2.7/lib-dynload/strop.so
7f270eabb000-7f270eabd000 rw-p 00004000 00:16 6394000 /python278/lib/python2.7/lib-dynload/strop.so
7f270eabd000-7f270eafd000 rw-p 00000000 00:00 0
7f270eafd000-7f270eb00000 r-xp 00000000 00:16 5568749 /python278/lib/python2.7/lib-dynload/fcntl.so
7f270eb00000-7f270ecff000 ---p 00003000 00:16 5568749 /python278/lib/python2.7/lib-dynload/fcntl.so
7f270ecff000-7f270ed01000 rw-p 00002000 00:16 5568749 /python278/lib/python2.7/lib-dynload/fcntl.so
7f270ed01000-7f270ed04000 r-xp 00000000 00:16 5568739 /python278/lib/python2.7/lib-dynload/_random.so
7f270ed04000-7f270ef03000 ---p 00003000 00:16 5568739 /python278/lib/python2.7/lib-dynload/_random.so
7f270ef03000-7f270ef04000 rw-p 00002000 00:16 5568739 /python278/lib/python2.7/lib-dynload/_random.so
4272 Aborted (core dumped)
Regards,
Adel
________________________________
From: Rob Godfrey <ro...@gmail.com>
Sent: Monday, February 6, 2017 7:09 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
wrote:
> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com> wrote:
> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
> >
> >> It seems odd that the client creates a _sender_ to the temporary queue
> >> that it will never send messages _to_ but will receive messages _from_.
> >>
> >>
> > This is because JMS semantics require the temporary node to have a
> lifetime
> > scoped to the session (not a link), so the JMS client has to create a
> > synthetic link which it uses simply to manage the lifetime of the dynamic
> > node. In order to not cause unintentional assigning of messages to a
> link
> > that will never actually be used for consumption, a sending link is used.
> > Note that in general JMS would expect that you should be able to send to
> a
> > temporary queue created in this way (since the point of temporary queues
> is
> > to use as a reply to)
> >
>
> Not really important here, but the lifetime is scoped to the
> Connection, not Session (agghhh JMS... :P)
>
That's what I thought I was typing... obviously my fingers were not
cooperating with my brain at that point :-)
-- Rob
>
> >
> >> Anyway, when the client creates a receiver with a dynamic source (and no
> >> dynamic-node-properties), the router will accept the link and assign a
> >> temporary address as the source. This is only useful in this use case
> if
> >> the broker has a way of knowing that the temporary address is reachable
> via
> >> the router network.
> >>
> >> There is a way to route dynamic termini to a broker. If an
> >> x-opt-qd.address property is included in the dynamic-node-properties,
> this
> >> address will be used to route the attach to the broker. I've never
> tested
> >> this with a dynamic target in a sender. It might not work.
> >
> >
> > And this really isn't something you'd be expecting a generic client (like
> > the JMS client) to know :-)
> >
> > -- Rob
> >
> >
> >>
> >>
> >> -Ted
> >>
> >>
> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
> >>
> >>> I've had a look at this. It would seem that Dispatch doesn't like what
> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
> >>> very nice way, and the client then doesnt notice that things have gone
> >>> south in a somewhat unexpected way.
> >>>
> >>> The client opens a sending link with 'dynamic' target in order to
> >>> create a dynamic node for use as a TemporaryQueue address/destination
> >>> object, which specific consumers/producers are then created against by
> >>> the application. Dispatch doesn't seem to like that but erroneously
> >>> attaches the link 'successfully', though doesnt set a target address
> >>> as is expected. The client then doesnt notice this happened (its
> >>> checking for the link being refused, which it wasn't), allowing the
> >>> application to proceed as far as creating consumers/procuers using the
> >>> TemporaryQueue object, with creation of the e.g Consumer then failing
> >>> since the attach doesnt contain the needed information and leads to
> >>> Dispatch detaching it with the error (though it again doesnt actually
> >>> indicate its refusing the link during the attach response, as it
> >>> probably should have in this case).
> >>>
> >>> Making the client detect the current failure and having it throw an
> >>> aexception from createTemporaryQueue is simple enough.
> >>>
> >>> Hacking the client to use a dynamic recieving link instead, an address
> >>> was returned by Dispatch in the attach response as expected, however a
> >>> consumer on the resulting TemporaryQueue object using this address
> >>> still didnt get the message I sent to the same place. If I also gave
> >>> some credit on the link backing the TemporaryQeueue object itself then
> >>> that link gets sent the message by Dispatch, though this of no use for
> >>> the JMS client.
> >>>
> >>> Needs some more investigation, and I'll need to discuss with some
> >>> folks more familiar with Dispatch.
> >>>
> >>> Robbie
> >>>
> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
> wrote:
> >>>
> >>>> Hello Robbie,
> >>>>
> >>>>
> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the reply
> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS Client.
> >>>>
> >>>>
> >>>> PS: As Rabih stated before, we are using the same connection and same
> >>>> session to create the JMSProducer for the request and the
> JMSConsumer for
> >>>> the reply.
> >>>>
> >>>>
> >>>> Exception
> >>>> -------------------
> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed due
> to
> >>>> an unrecoverable error.
> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
> >>>> eConsumer.java:330)
> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
> >>>> sumer.java:196)
> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> >>>> ssorImpl.java:62)
> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> >>>> thodAccessorImpl.java:43)
> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
> >>>> at com.intellij.rt.execution.application.AppMain.main(
> AppMain.java:147)
> >>>> Caused by: javax.jms.JMSException: No route to the destination node
> >>>> [condition = qd:no-route-to-dest]
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >>>> tion(AmqpSupport.java:150)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >>>> tion(AmqpSupport.java:105)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
> >>>> elyClosed(AmqpAbstractResource.java:147)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
> >>>> s(AmqpProvider.java:795)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
> >>>> mqpProvider.java:90)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
> >>>> ovider.java:699)
> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
> >>>> Executors.java:511)
> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> >>>> Executor.java:1142)
> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> >>>> lExecutor.java:617)
> >>>> at java.lang.Thread.run(Thread.java:745)
> >>>>
> >>>>
> >>>> -------------------
> >>>> Dispatch Router (PN_TRACE_FRM=1)
> >>>> -------------------
> >>>>
> >>>> [832220]: <- SASL
> >>>> [832220]: -> SASL
> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
> >>>> MBOL[:ANONYMOUS]]
> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
> >>>> initial-response=b"", hostname="host-name"]
> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
> >>>> [832220]: <- AMQP
> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
> a334-44c3-954a-2dd910161411:1",
> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
> >>>> L[:"sole-connection-for-container"], properties={:product="QpidJMS",
> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
> >>>> [832220]: -> AMQP
> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> >>>> offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-
> dispatch-router",
> >>>> :version="0.7.0"}]
> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> >>>> outgoing-window=2147483647, handle-max=65535]
> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
> >>>> incoming-window=61, outgoing-window=2147483647]
> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> >>>> outgoing-window=2147483647, handle-max=65535]
> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
> >>>> incoming-window=61, outgoing-window=2147483647]
> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]],
> >>>> target=@target(41) [address="$management", durable=0,
> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
> >>>> initial-delivery-count=0]
> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list",
> >>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
> queue]],
> >>>> initial-delivery-count=0, max-message-size=0]
> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> delivery-count=0,
> >>>> link-credit=250, drain=false]
> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> [],
> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
> timeout=0,
> >>>> dynamic=true, dynamic-node-properties={:"lif
> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
> temporary-queue"]],
> >>>> incomplete-unsettled=false, initial-delivery-count=0]
> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> role=true,
> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []},
> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
> initial-delivery-count=0,
> >>>> max-message-size=0]
> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> delivery-count=0,
> >>>> link-credit=250, drain=false]
> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=true,
> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [durable=0,
> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> >>>> default-outcome=@modified(39) [delivery-failed=true],
> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> >>>> :"amqp:released:list", :"amqp:modified:list"],
> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41) []]
> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=false,
> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0,
> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
> >>>> destination node"]]
> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"0",
> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
> >>>> x04addr\xa1\x0dbrokerMachine"
> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> delivery-count=1,
> >>>> link-credit=250, drain=false]
> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
> >>>> settled=true, state=@accepted(36) []]
> >>>> [832220]:0 <- @close(24) []
> >>>> [832220]: <- EOS
> >>>> [832220]:0 -> @close(24) []
> >>>> [832220]: -> EOS
> >>>> Closed x.x.x.x:8961
> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >>>>
> >>>> ------------------
> >>>> JMS Client (PN_TRACE_FRM=1)
> >>>> ------------------
> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
> 4a22-9b22-69d27a017a83:1',
> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
> connection-for-container],
> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM: 1.8.0_111,
> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
> >>>> [1244186219:0] <- Open{ containerId='router.10200', hostname='null',
> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
> ANONYMOUS-RELAY],
> >>>> desiredCapabilities=null, properties={product=qpid-dispatch-router,
> >>>> version=0.7.0}}
> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> 3293ffc57168:1:1:1',
> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> amqp:rejected:list],
> >>>> capabilities=null}, target=Target{address='$management',
> durable=NONE,
> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> 3293ffc57168:1:1:1',
> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> amqp:rejected:list],
> >>>> capabilities=null}, target=Target{address='$management',
> durable=NONE,
> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> deliveryCount=0,
> >>>> linkCredit=250, available=null, drain=false, echo=false,
> properties=null}
> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> outcomes=null,
> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> outcomes=null,
> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> deliveryCount=0,
> >>>> linkCredit=250, available=null, drain=false, echo=false,
> properties=null}
> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >>>> source=Source{address='null', durable=NONE, expiryPolicy=LINK_DETACH,
> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
> deliveryFailed=true,
> >>>> undeliverableHere=null, messageAnnotations=null},
> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list,
> >>>> amqp:modified:list], capabilities=[temporary-queue]},
> >>>> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> capabilities=null},
> >>>> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
> >>>> maxMessageSize=null, offeredCapabilities=null,
> desiredCapabilities=null,
> >>>> properties=null}
> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> outcomes=null,
> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> >>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
> >>>> error=Error{condition=qd:no-route-to-dest, description='No route to
> the
> >>>> destination node', info=null}}
> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
> state=null,
> >>>> resume=false, aborted=false, batchable=false} (312)
> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@
> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> deliveryCount=1,
> >>>> linkCredit=250, available=null, drain=false, echo=false,
> properties=null}
> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
> >>>> settled=true, state=Accepted{}, batchable=false}
> >>>> [1244186219:0] -> Close{error=null}
> >>>> [1244186219:0] <- Close{error=null}
> >>>>
> >>>> Regards,
> >>>>
> >>>> Adel
> >>>>
> >>>> ________________________________
> >>>> From: Robbie Gemmell <ro...@gmail.com>
> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
> >>>> To: users@qpid.apache.org
> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >>>>
> >>>> That looks fine at first glance. Its possible there is an issue in
> >>>> there needing looked it. I am travelling this week so may not get to
> >>>> look until afterwards, but will try to give things a look at. If you
> >>>> could give more detail on the exception and maybe a protocol trace
> >>>> that might be useful.
> >>>>
> >>>> Robbie
> >>>>
> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
> >>>>
> >>>>> Hello Robbie,
> >>>>>
> >>>>> Thanks for you for your answer.
> >>>>> I will try the solutions you proposed.
> >>>>>
> >>>>> I need just need one clarification. Concerning the Jms, I already
> tried
> >>>>> to
> >>>>> use a temporary queue but it didn't work. May be i am using it wrong.
> >>>>> Here
> >>>>> is what i did:
> >>>>>
> >>>>> ...
> >>>>> Session session = connection.createSession(false,
> >>>>> Session.AUTO_ACKNOWLEDGE);
> >>>>> Queue queue = session.createQueue("$management");
> >>>>> MessageProducer producer = session.createProducer(queue);
> >>>>>
> >>>>> Queue tempDest = session.createTemporaryQueue();
> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDest);
> >>>>> connection.start();
> >>>>>
> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
> >>>>> objectMessage.setJMSReplyTo(tempDest);
> >>>>> //fill the rest of the parameters ...
> >>>>> producer.send(objectMessage);
> >>>>> ObjectMessage replyMessage = (ObjectMessage)
> >>>>> responseConsumer.receive(1000);
> >>>>> ...
> >>>>>
> >>>>> I was getting an exception on the .receive() from the dispatch router
> >>>>> saying that the reply-to address is bad...
> >>>>> Should i create the temporary queue and the consumer from a different
> >>>>> session then the producer?
> >>>>>
> >>>>> Best regards,
> >>>>> Rabih
> >>>>>
> >>>>>
> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
> >>>>> robbie.gemmell@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> The session.createTemporaryQueue(); method is how JMS creates
> >>>>>> temporary destinations for use in reply-to scenarios. The dispatch
> >>>>>> tools will be doing essentially the same thing under the covers for
> >>>>>> theirs.
> >>>>>>
> >>>>>> Both work by creating a 'dynamic' link attachment, with the server
> >>>>>> returning an address for the dynamic attach to the client. One key
> >>>>>> difference is with JMS you create the temporary destination (for
> which
> >>>>>> the client uses a dynamic sender link to create), then separately
> >>>>>> create a receiver using it (and in turn the address associated with
> >>>>>> it), whereas non-JMS client/tools will typically just create a
> single
> >>>>>> dynamic receiver link and use its address for the reply-to.
> >>>>>>
> >>>>>> For proton-j, there aren't any examples for this, but you you
> >>>>>> essentially would change the link opening to not specify an address,
> >>>>>> and instead set the source(for a receiver) or target (for a sender)
> to
> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
> remoteTarget
> >>>>>> once the link had been reemotely attached, and get its
> >>>>>> (server-generated) address, then use this as your reply-to.
> >>>>>>
> >>>>>> Robbie
> >>>>>>
> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
> wrote:
> >>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like you
> >>>>>>> suggested, it worked.
> >>>>>>> But I cheated a little to make it work because I did not find a
> way in
> >>>>>>>
> >>>>>> JMS
> >>>>>>
> >>>>>>> to create a local queue. So I created a queue on the qpid-dispatch
> and
> >>>>>>>
> >>>>>> read
> >>>>>>
> >>>>>>> the result from it. You can check the attached code.
> >>>>>>>
> >>>>>>> Is there any way using qpid-jms to create a local queue on the
> client
> >>>>>>>
> >>>>>> side
> >>>>>>
> >>>>>>> to serve as a reply to address?
> >>>>>>>
> >>>>>>> For the proton-j test, I have the same question as above. I saw
> that
> >>>>>>> it
> >>>>>>>
> >>>>>> can
> >>>>>>
> >>>>>>> be done with the C++ API. Are there any examples for proton-j or
> >>>>>>>
> >>>>>> something
> >>>>>>
> >>>>>>> that can help me?
> >>>>>>>
> >>>>>>> I saw may be in proton we don't need a local queue, may be we can
> get
> >>>>>>> the
> >>>>>>> address of the consumer directly and pass it in reply-to field. Is
> it
> >>>>>>> correct?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Rabih
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
> >>>>>>> rob.j.godfrey@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>>
> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
> >>>>>>>>>> To: users@qpid.apache.org
> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid
> Jms
> >>>>>>>>>>
> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you
> told
> >>>>>>>>>>>>
> >>>>>>>>>>> me
> >>>>>>
> >>>>>>> Robbie and it worked.
> >>>>>>>>>>>>
> >>>>>>>>>>>> But like the proton-j case, the connector is not being
> created on
> >>>>>>>>>>>> the
> >>>>>>>>>>>> Qpid-dispatch side.
> >>>>>>>>>>>> I attached the amqp communication into this mail.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> The last frame in that file is incomplete (the previous error
> >>>>>>>>>>>
> >>>>>>>>>> regarding the
> >>>>>>>>>
> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
> frame
> >>>>>>>>>>>
> >>>>>>>>>> is
> >>>>>>
> >>>>>>> likely
> >>>>>>>>>
> >>>>>>>>>> the response which would indicate the success or otherwise of
> the
> >>>>>>>>>>>
> >>>>>>>>>> frame. Is
> >>>>>>>>>
> >>>>>>>>>> there anything logged by the router?
> >>>>>>>>>>>
> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
> simpler
> >>>>>>>>>>> for
> >>>>>>>>>>>
> >>>>>>>>>> this
> >>>>>>>>>
> >>>>>>>>>> sort of thing in my view.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more helpful.
> >>>>>>>>>> You
> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
> since
> >>>>>>>>>> it
> >>>>>>>>>> uses proton-j.
> >>>>>>>>>>
> >>>>>>>>>> One key difference from the qdmanage case is you are not
> setting a
> >>>>>>>>>> reply-to value or correlation-id to use along with it. I don't
> know
> >>>>>>>>>>
> >>>>>>>>> if
> >>>>>>
> >>>>>>> the router cares about not being able to send a response or not
> >>>>>>>>>> though, but it might.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> You could add the following to your dispatch router conf file
> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable trace
> >>>>>>>>>
> >>>>>>>> logging)
> >>>>>>
> >>>>>>>
> >>>>>>>>> log {
> >>>>>>>>> module: DEFAULT
> >>>>>>>>> enable: trace+
> >>>>>>>>> output: /path/to/log/qdrouterd.log
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> When you run your management request, you will see proton frame
> >>>>>>>>> trace
> >>>>>>>>> and
> >>>>>>>>> you will see additional logging out of the dispatch Python agent
> -
> >>>>>>>>> something like the following -
> >>>>>>>>>
> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
> >>>>>>>>> Message(address=None,
> >>>>>>>>> properties={'operation': 'CREATE', 'type':
> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
> >>>>>>>>>
> >>>>>>>> 'rabih.connector'},
> >>>>>>
> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
> >>>>>>>>> correlation_id=1L)
> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
> 5673:rabih.connector,
> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
> >>>>>>>>> verifyHostName=True)
> >>>>>>>>>
> >>>>>>>>> The Python management agent will not process your request if
> there
> >>>>>>>>> is
> >>>>>>>>>
> >>>>>>>> no
> >>>>>>
> >>>>>>> reply_to as seen here -
> >>>>>>>>>
> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
> because
> >>>>>>>> there
> >>>>>>>> is
> >>>>>>>> a reply-to doesn't mean that the sender will be around to actually
> >>>>>>>> hear
> >>>>>>>> the
> >>>>>>>> reply, so it seems a bit arbitrary to say that because we *know*
> the
> >>>>>>>> sender
> >>>>>>>> won't learn of the outcome that we won't do anything... The spec
> >>>>>>>> draft
> >>>>>>>> doesn't currently say anything about this (obviously it should
> do),
> >>>>>>>> but
> >>>>>>>>
> >>>>>>> my
> >>>>>>
> >>>>>>> expectation would certainly be that a request would be processed
> even
> >>>>>>>> if
> >>>>>>>> the replyTo address was not present (or ended up not routing
> >>>>>>>> anywhere).
> >>>>>>>> This is also how the Qpid Broker for Java implements this case.
> >>>>>>>>
> >>>>>>>> -- Rob
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Robbie
> >>>>>>>>>>
> >>>>>>>>>> ------------------------------------------------------------
> >>>>>>>>>>
> >>>>>>>>> ---------
> >>>>>>
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> ------------------------------------------------------------
> >>>>>>>>> ---------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------------------------------------
> ---------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>>>>>
> >>>>>>
> >>>>>> ------------------------------------------------------------
> ---------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Rob Godfrey <ro...@gmail.com>.
On 6 February 2017 at 19:03, Robbie Gemmell <ro...@gmail.com>
wrote:
> On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com> wrote:
> > On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
> >
> >> It seems odd that the client creates a _sender_ to the temporary queue
> >> that it will never send messages _to_ but will receive messages _from_.
> >>
> >>
> > This is because JMS semantics require the temporary node to have a
> lifetime
> > scoped to the session (not a link), so the JMS client has to create a
> > synthetic link which it uses simply to manage the lifetime of the dynamic
> > node. In order to not cause unintentional assigning of messages to a
> link
> > that will never actually be used for consumption, a sending link is used.
> > Note that in general JMS would expect that you should be able to send to
> a
> > temporary queue created in this way (since the point of temporary queues
> is
> > to use as a reply to)
> >
>
> Not really important here, but the lifetime is scoped to the
> Connection, not Session (agghhh JMS... :P)
>
That's what I thought I was typing... obviously my fingers were not
cooperating with my brain at that point :-)
-- Rob
>
> >
> >> Anyway, when the client creates a receiver with a dynamic source (and no
> >> dynamic-node-properties), the router will accept the link and assign a
> >> temporary address as the source. This is only useful in this use case
> if
> >> the broker has a way of knowing that the temporary address is reachable
> via
> >> the router network.
> >>
> >> There is a way to route dynamic termini to a broker. If an
> >> x-opt-qd.address property is included in the dynamic-node-properties,
> this
> >> address will be used to route the attach to the broker. I've never
> tested
> >> this with a dynamic target in a sender. It might not work.
> >
> >
> > And this really isn't something you'd be expecting a generic client (like
> > the JMS client) to know :-)
> >
> > -- Rob
> >
> >
> >>
> >>
> >> -Ted
> >>
> >>
> >> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
> >>
> >>> I've had a look at this. It would seem that Dispatch doesn't like what
> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
> >>> very nice way, and the client then doesnt notice that things have gone
> >>> south in a somewhat unexpected way.
> >>>
> >>> The client opens a sending link with 'dynamic' target in order to
> >>> create a dynamic node for use as a TemporaryQueue address/destination
> >>> object, which specific consumers/producers are then created against by
> >>> the application. Dispatch doesn't seem to like that but erroneously
> >>> attaches the link 'successfully', though doesnt set a target address
> >>> as is expected. The client then doesnt notice this happened (its
> >>> checking for the link being refused, which it wasn't), allowing the
> >>> application to proceed as far as creating consumers/procuers using the
> >>> TemporaryQueue object, with creation of the e.g Consumer then failing
> >>> since the attach doesnt contain the needed information and leads to
> >>> Dispatch detaching it with the error (though it again doesnt actually
> >>> indicate its refusing the link during the attach response, as it
> >>> probably should have in this case).
> >>>
> >>> Making the client detect the current failure and having it throw an
> >>> aexception from createTemporaryQueue is simple enough.
> >>>
> >>> Hacking the client to use a dynamic recieving link instead, an address
> >>> was returned by Dispatch in the attach response as expected, however a
> >>> consumer on the resulting TemporaryQueue object using this address
> >>> still didnt get the message I sent to the same place. If I also gave
> >>> some credit on the link backing the TemporaryQeueue object itself then
> >>> that link gets sent the message by Dispatch, though this of no use for
> >>> the JMS client.
> >>>
> >>> Needs some more investigation, and I'll need to discuss with some
> >>> folks more familiar with Dispatch.
> >>>
> >>> Robbie
> >>>
> >>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com>
> wrote:
> >>>
> >>>> Hello Robbie,
> >>>>
> >>>>
> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the reply
> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS Client.
> >>>>
> >>>>
> >>>> PS: As Rabih stated before, we are using the same connection and same
> >>>> session to create the JMSProducer for the request and the
> JMSConsumer for
> >>>> the reply.
> >>>>
> >>>>
> >>>> Exception
> >>>> -------------------
> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed due
> to
> >>>> an unrecoverable error.
> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
> >>>> eConsumer.java:330)
> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
> >>>> sumer.java:196)
> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> >>>> ssorImpl.java:62)
> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> >>>> thodAccessorImpl.java:43)
> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
> >>>> at com.intellij.rt.execution.application.AppMain.main(
> AppMain.java:147)
> >>>> Caused by: javax.jms.JMSException: No route to the destination node
> >>>> [condition = qd:no-route-to-dest]
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >>>> tion(AmqpSupport.java:150)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >>>> tion(AmqpSupport.java:105)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
> >>>> elyClosed(AmqpAbstractResource.java:147)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
> >>>> s(AmqpProvider.java:795)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
> >>>> mqpProvider.java:90)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
> >>>> ovider.java:699)
> >>>> at java.util.concurrent.Executors$RunnableAdapter.call(
> >>>> Executors.java:511)
> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> >>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> >>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
> >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> >>>> Executor.java:1142)
> >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> >>>> lExecutor.java:617)
> >>>> at java.lang.Thread.run(Thread.java:745)
> >>>>
> >>>>
> >>>> -------------------
> >>>> Dispatch Router (PN_TRACE_FRM=1)
> >>>> -------------------
> >>>>
> >>>> [832220]: <- SASL
> >>>> [832220]: -> SASL
> >>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
> >>>> MBOL[:ANONYMOUS]]
> >>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
> >>>> initial-response=b"", hostname="host-name"]
> >>>> [832220]:0 -> @sasl-outcome(68) [code=0]
> >>>> [832220]: <- AMQP
> >>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
> a334-44c3-954a-2dd910161411:1",
> >>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
> >>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
> >>>> L[:"sole-connection-for-container"], properties={:product="QpidJMS",
> >>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
> >>>> Corporation, OS: Windows 7, 6.1, amd64"}]
> >>>> [832220]: -> AMQP
> >>>> [832220]:0 -> @open(16) [container-id="router.10200",
> >>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> >>>> offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-
> dispatch-router",
> >>>> :version="0.7.0"}]
> >>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> >>>> outgoing-window=2147483647, handle-max=65535]
> >>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
> >>>> incoming-window=61, outgoing-window=2147483647]
> >>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> >>>> outgoing-window=2147483647, handle-max=65535]
> >>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
> >>>> incoming-window=61, outgoing-window=2147483647]
> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]],
> >>>> target=@target(41) [address="$management", durable=0,
> >>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
> >>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
> >>>> initial-delivery-count=0]
> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
> >>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> >>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> >>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
> >>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list",
> >>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
> >>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:
> queue]],
> >>>> initial-delivery-count=0, max-message-size=0]
> >>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> delivery-count=0,
> >>>> link-credit=250, drain=false]
> >>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> >>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> [],
> >>>> target=@target(41) [durable=0, expiry-policy=:"link-detach",
> timeout=0,
> >>>> dynamic=true, dynamic-node-properties={:"lif
> >>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"
> temporary-queue"]],
> >>>> incomplete-unsettled=false, initial-delivery-count=0]
> >>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
> >>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> role=true,
> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
> >>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []},
> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]],
> initial-delivery-count=0,
> >>>> max-message-size=0]
> >>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> delivery-count=0,
> >>>> link-credit=250, drain=false]
> >>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=true,
> >>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [durable=0,
> >>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> >>>> default-outcome=@modified(39) [delivery-failed=true],
> >>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> >>>> :"amqp:released:list", :"amqp:modified:list"],
> >>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41) []]
> >>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
> >>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=false,
> >>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
> >>>> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0,
> >>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
> >>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
> >>>> [condition=:"qd:no-route-to-dest", description="No route to the
> >>>> destination node"]]
> >>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
> >>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"0",
> >>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
> >>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
> >>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
> >>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
> >>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
> >>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
> >>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
> >>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
> >>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
> >>>> x04addr\xa1\x0dbrokerMachine"
> >>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
> >>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0,
> delivery-count=1,
> >>>> link-credit=250, drain=false]
> >>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
> >>>> settled=true, state=@accepted(36) []]
> >>>> [832220]:0 <- @close(24) []
> >>>> [832220]: <- EOS
> >>>> [832220]:0 -> @close(24) []
> >>>> [832220]: -> EOS
> >>>> Closed x.x.x.x:8961
> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >>>> Unexpected poll events: 0020 on x.x.x.x:8961
> >>>>
> >>>> ------------------
> >>>> JMS Client (PN_TRACE_FRM=1)
> >>>> ------------------
> >>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-
> 4a22-9b22-69d27a017a83:1',
> >>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
> >>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
> >>>> offeredCapabilities=null, desiredCapabilities=[sole-
> connection-for-container],
> >>>> properties={product=QpidJMS, version=0.11.1, platform=JVM: 1.8.0_111,
> >>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
> >>>> [1244186219:0] <- Open{ containerId='router.10200', hostname='null',
> >>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
> >>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[
> ANONYMOUS-RELAY],
> >>>> desiredCapabilities=null, properties={product=qpid-dispatch-router,
> >>>> version=0.7.0}}
> >>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
> >>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
> >>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> 3293ffc57168:1:1:1',
> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> amqp:rejected:list],
> >>>> capabilities=null}, target=Target{address='$management',
> durable=NONE,
> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
> >>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >>>> source=Source{address='ID:53f2be62-ad72-4193-a824-
> 3293ffc57168:1:1:1',
> >>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
> >>>> defaultOutcome=null, outcomes=[amqp:accepted:list,
> amqp:rejected:list],
> >>>> capabilities=null}, target=Target{address='$management',
> durable=NONE,
> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> >>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> deliveryCount=0,
> >>>> linkCredit=250, available=null, drain=false, echo=false,
> properties=null}
> >>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> outcomes=null,
> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >>>> incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
> >>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
> >>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> outcomes=null,
> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
> >>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
> >>>> capabilities=[temporary-queue]}, unsettled=null,
> >>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> deliveryCount=0,
> >>>> linkCredit=250, available=null, drain=false, echo=false,
> properties=null}
> >>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> >>>> source=Source{address='null', durable=NONE, expiryPolicy=LINK_DETACH,
> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >>>> distributionMode=null, filter=null, defaultOutcome=Modified{
> deliveryFailed=true,
> >>>> undeliverableHere=null, messageAnnotations=null},
> >>>> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list,
> >>>> amqp:modified:list], capabilities=[temporary-queue]},
> >>>> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> capabilities=null},
> >>>> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
> >>>> maxMessageSize=null, offeredCapabilities=null,
> desiredCapabilities=null,
> >>>> properties=null}
> >>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
> >>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
> >>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> >>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> outcomes=null,
> >>>> capabilities=null}, target=Target{address='null', durable=NONE,
> >>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> >>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> >>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
> >>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> >>>> [1244186219:1] <- Detach{handle=1, closed=true,
> >>>> error=Error{condition=qd:no-route-to-dest, description='No route to
> the
> >>>> destination node', info=null}}
> >>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
> >>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
> >>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null,
> state=null,
> >>>> resume=false, aborted=false, batchable=false} (312)
> >>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
> >>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
> >>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@
> >>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
> >>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
> >>>> apache.qpid.dispatch.connector\xa1\x09operation\
> >>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
> >>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
> >>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
> >>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
> >>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0,
> deliveryCount=1,
> >>>> linkCredit=250, available=null, drain=false, echo=false,
> properties=null}
> >>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
> >>>> settled=true, state=Accepted{}, batchable=false}
> >>>> [1244186219:0] -> Close{error=null}
> >>>> [1244186219:0] <- Close{error=null}
> >>>>
> >>>> Regards,
> >>>>
> >>>> Adel
> >>>>
> >>>> ________________________________
> >>>> From: Robbie Gemmell <ro...@gmail.com>
> >>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
> >>>> To: users@qpid.apache.org
> >>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >>>>
> >>>> That looks fine at first glance. Its possible there is an issue in
> >>>> there needing looked it. I am travelling this week so may not get to
> >>>> look until afterwards, but will try to give things a look at. If you
> >>>> could give more detail on the exception and maybe a protocol trace
> >>>> that might be useful.
> >>>>
> >>>> Robbie
> >>>>
> >>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
> >>>>
> >>>>> Hello Robbie,
> >>>>>
> >>>>> Thanks for you for your answer.
> >>>>> I will try the solutions you proposed.
> >>>>>
> >>>>> I need just need one clarification. Concerning the Jms, I already
> tried
> >>>>> to
> >>>>> use a temporary queue but it didn't work. May be i am using it wrong.
> >>>>> Here
> >>>>> is what i did:
> >>>>>
> >>>>> ...
> >>>>> Session session = connection.createSession(false,
> >>>>> Session.AUTO_ACKNOWLEDGE);
> >>>>> Queue queue = session.createQueue("$management");
> >>>>> MessageProducer producer = session.createProducer(queue);
> >>>>>
> >>>>> Queue tempDest = session.createTemporaryQueue();
> >>>>> MessageConsumer responseConsumer = session.createConsumer(tempDest);
> >>>>> connection.start();
> >>>>>
> >>>>> ObjectMessage objectMessage = session.createObjectMessage();
> >>>>> objectMessage.setJMSReplyTo(tempDest);
> >>>>> //fill the rest of the parameters ...
> >>>>> producer.send(objectMessage);
> >>>>> ObjectMessage replyMessage = (ObjectMessage)
> >>>>> responseConsumer.receive(1000);
> >>>>> ...
> >>>>>
> >>>>> I was getting an exception on the .receive() from the dispatch router
> >>>>> saying that the reply-to address is bad...
> >>>>> Should i create the temporary queue and the consumer from a different
> >>>>> session then the producer?
> >>>>>
> >>>>> Best regards,
> >>>>> Rabih
> >>>>>
> >>>>>
> >>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
> >>>>> robbie.gemmell@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> The session.createTemporaryQueue(); method is how JMS creates
> >>>>>> temporary destinations for use in reply-to scenarios. The dispatch
> >>>>>> tools will be doing essentially the same thing under the covers for
> >>>>>> theirs.
> >>>>>>
> >>>>>> Both work by creating a 'dynamic' link attachment, with the server
> >>>>>> returning an address for the dynamic attach to the client. One key
> >>>>>> difference is with JMS you create the temporary destination (for
> which
> >>>>>> the client uses a dynamic sender link to create), then separately
> >>>>>> create a receiver using it (and in turn the address associated with
> >>>>>> it), whereas non-JMS client/tools will typically just create a
> single
> >>>>>> dynamic receiver link and use its address for the reply-to.
> >>>>>>
> >>>>>> For proton-j, there aren't any examples for this, but you you
> >>>>>> essentially would change the link opening to not specify an address,
> >>>>>> and instead set the source(for a receiver) or target (for a sender)
> to
> >>>>>> be 'dynamic'. You would then inspect the remoteSource or
> remoteTarget
> >>>>>> once the link had been reemotely attached, and get its
> >>>>>> (server-generated) address, then use this as your reply-to.
> >>>>>>
> >>>>>> Robbie
> >>>>>>
> >>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com>
> wrote:
> >>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like you
> >>>>>>> suggested, it worked.
> >>>>>>> But I cheated a little to make it work because I did not find a
> way in
> >>>>>>>
> >>>>>> JMS
> >>>>>>
> >>>>>>> to create a local queue. So I created a queue on the qpid-dispatch
> and
> >>>>>>>
> >>>>>> read
> >>>>>>
> >>>>>>> the result from it. You can check the attached code.
> >>>>>>>
> >>>>>>> Is there any way using qpid-jms to create a local queue on the
> client
> >>>>>>>
> >>>>>> side
> >>>>>>
> >>>>>>> to serve as a reply to address?
> >>>>>>>
> >>>>>>> For the proton-j test, I have the same question as above. I saw
> that
> >>>>>>> it
> >>>>>>>
> >>>>>> can
> >>>>>>
> >>>>>>> be done with the C++ API. Are there any examples for proton-j or
> >>>>>>>
> >>>>>> something
> >>>>>>
> >>>>>>> that can help me?
> >>>>>>>
> >>>>>>> I saw may be in proton we don't need a local queue, may be we can
> get
> >>>>>>> the
> >>>>>>> address of the consumer directly and pass it in reply-to field. Is
> it
> >>>>>>> correct?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Rabih
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
> >>>>>>> rob.j.godfrey@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>>
> >>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
> >>>>>>>>>> To: users@qpid.apache.org
> >>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
> >>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid
> Jms
> >>>>>>>>>>
> >>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you
> told
> >>>>>>>>>>>>
> >>>>>>>>>>> me
> >>>>>>
> >>>>>>> Robbie and it worked.
> >>>>>>>>>>>>
> >>>>>>>>>>>> But like the proton-j case, the connector is not being
> created on
> >>>>>>>>>>>> the
> >>>>>>>>>>>> Qpid-dispatch side.
> >>>>>>>>>>>> I attached the amqp communication into this mail.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> The last frame in that file is incomplete (the previous error
> >>>>>>>>>>>
> >>>>>>>>>> regarding the
> >>>>>>>>>
> >>>>>>>>>> map body may or may not be a wireshark issue),but that last
> frame
> >>>>>>>>>>>
> >>>>>>>>>> is
> >>>>>>
> >>>>>>> likely
> >>>>>>>>>
> >>>>>>>>>> the response which would indicate the success or otherwise of
> the
> >>>>>>>>>>>
> >>>>>>>>>> frame. Is
> >>>>>>>>>
> >>>>>>>>>> there anything logged by the router?
> >>>>>>>>>>>
> >>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is
> simpler
> >>>>>>>>>>> for
> >>>>>>>>>>>
> >>>>>>>>>> this
> >>>>>>>>>
> >>>>>>>>>> sort of thing in my view.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> As Gordon suggests, the proton trace logs might be more helpful.
> >>>>>>>>>> You
> >>>>>>>>>> can also do that with proton-j, and this the JMS client too
> since
> >>>>>>>>>> it
> >>>>>>>>>> uses proton-j.
> >>>>>>>>>>
> >>>>>>>>>> One key difference from the qdmanage case is you are not
> setting a
> >>>>>>>>>> reply-to value or correlation-id to use along with it. I don't
> know
> >>>>>>>>>>
> >>>>>>>>> if
> >>>>>>
> >>>>>>> the router cares about not being able to send a response or not
> >>>>>>>>>> though, but it might.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> You could add the following to your dispatch router conf file
> >>>>>>>>> (qdrouterd.conf) and restart the router (This will enable trace
> >>>>>>>>>
> >>>>>>>> logging)
> >>>>>>
> >>>>>>>
> >>>>>>>>> log {
> >>>>>>>>> module: DEFAULT
> >>>>>>>>> enable: trace+
> >>>>>>>>> output: /path/to/log/qdrouterd.log
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> When you run your management request, you will see proton frame
> >>>>>>>>> trace
> >>>>>>>>> and
> >>>>>>>>> you will see additional logging out of the dispatch Python agent
> -
> >>>>>>>>> something like the following -
> >>>>>>>>>
> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
> >>>>>>>>> Message(address=None,
> >>>>>>>>> properties={'operation': 'CREATE', 'type':
> >>>>>>>>> 'org.apache.qpid.dispatch.connector',
> >>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
> >>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
> >>>>>>>>>
> >>>>>>>> 'rabih.connector'},
> >>>>>>
> >>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
> >>>>>>>>> correlation_id=1L)
> >>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
> >>>>>>>>> broker-machine:5673 proto=any, role=route-container
> >>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
> >>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
> >>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:
> 5673:rabih.connector,
> >>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
> >>>>>>>>> name=rabih.connector, port=5673, role=route-container,
> >>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
> >>>>>>>>> verifyHostName=True)
> >>>>>>>>>
> >>>>>>>>> The Python management agent will not process your request if
> there
> >>>>>>>>> is
> >>>>>>>>>
> >>>>>>>> no
> >>>>>>
> >>>>>>> reply_to as seen here -
> >>>>>>>>>
> >>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
> >>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Can I ask why the agent doesn't process the request? Just
> because
> >>>>>>>> there
> >>>>>>>> is
> >>>>>>>> a reply-to doesn't mean that the sender will be around to actually
> >>>>>>>> hear
> >>>>>>>> the
> >>>>>>>> reply, so it seems a bit arbitrary to say that because we *know*
> the
> >>>>>>>> sender
> >>>>>>>> won't learn of the outcome that we won't do anything... The spec
> >>>>>>>> draft
> >>>>>>>> doesn't currently say anything about this (obviously it should
> do),
> >>>>>>>> but
> >>>>>>>>
> >>>>>>> my
> >>>>>>
> >>>>>>> expectation would certainly be that a request would be processed
> even
> >>>>>>>> if
> >>>>>>>> the replyTo address was not present (or ended up not routing
> >>>>>>>> anywhere).
> >>>>>>>> This is also how the Qpid Broker for Java implements this case.
> >>>>>>>>
> >>>>>>>> -- Rob
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Robbie
> >>>>>>>>>>
> >>>>>>>>>> ------------------------------------------------------------
> >>>>>>>>>>
> >>>>>>>>> ---------
> >>>>>>
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> ------------------------------------------------------------
> >>>>>>>>> ---------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------------------------------------
> ---------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>>>>>
> >>>>>>
> >>>>>> ------------------------------------------------------------
> ---------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>>>>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Robbie Gemmell <ro...@gmail.com>.
On 6 February 2017 at 17:50, Rob Godfrey <ro...@gmail.com> wrote:
> On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
>
>> It seems odd that the client creates a _sender_ to the temporary queue
>> that it will never send messages _to_ but will receive messages _from_.
>>
>>
> This is because JMS semantics require the temporary node to have a lifetime
> scoped to the session (not a link), so the JMS client has to create a
> synthetic link which it uses simply to manage the lifetime of the dynamic
> node. In order to not cause unintentional assigning of messages to a link
> that will never actually be used for consumption, a sending link is used.
> Note that in general JMS would expect that you should be able to send to a
> temporary queue created in this way (since the point of temporary queues is
> to use as a reply to)
>
Not really important here, but the lifetime is scoped to the
Connection, not Session (agghhh JMS... :P)
>
>> Anyway, when the client creates a receiver with a dynamic source (and no
>> dynamic-node-properties), the router will accept the link and assign a
>> temporary address as the source. This is only useful in this use case if
>> the broker has a way of knowing that the temporary address is reachable via
>> the router network.
>>
>> There is a way to route dynamic termini to a broker. If an
>> x-opt-qd.address property is included in the dynamic-node-properties, this
>> address will be used to route the attach to the broker. I've never tested
>> this with a dynamic target in a sender. It might not work.
>
>
> And this really isn't something you'd be expecting a generic client (like
> the JMS client) to know :-)
>
> -- Rob
>
>
>>
>>
>> -Ted
>>
>>
>> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
>>
>>> I've had a look at this. It would seem that Dispatch doesn't like what
>>> the client is doing for createTemporaryQueue, but doesn't fail in a
>>> very nice way, and the client then doesnt notice that things have gone
>>> south in a somewhat unexpected way.
>>>
>>> The client opens a sending link with 'dynamic' target in order to
>>> create a dynamic node for use as a TemporaryQueue address/destination
>>> object, which specific consumers/producers are then created against by
>>> the application. Dispatch doesn't seem to like that but erroneously
>>> attaches the link 'successfully', though doesnt set a target address
>>> as is expected. The client then doesnt notice this happened (its
>>> checking for the link being refused, which it wasn't), allowing the
>>> application to proceed as far as creating consumers/procuers using the
>>> TemporaryQueue object, with creation of the e.g Consumer then failing
>>> since the attach doesnt contain the needed information and leads to
>>> Dispatch detaching it with the error (though it again doesnt actually
>>> indicate its refusing the link during the attach response, as it
>>> probably should have in this case).
>>>
>>> Making the client detect the current failure and having it throw an
>>> aexception from createTemporaryQueue is simple enough.
>>>
>>> Hacking the client to use a dynamic recieving link instead, an address
>>> was returned by Dispatch in the attach response as expected, however a
>>> consumer on the resulting TemporaryQueue object using this address
>>> still didnt get the message I sent to the same place. If I also gave
>>> some credit on the link backing the TemporaryQeueue object itself then
>>> that link gets sent the message by Dispatch, though this of no use for
>>> the JMS client.
>>>
>>> Needs some more investigation, and I'll need to discuss with some
>>> folks more familiar with Dispatch.
>>>
>>> Robbie
>>>
>>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com> wrote:
>>>
>>>> Hello Robbie,
>>>>
>>>>
>>>> I replaced the "createQueue" with "createTemporaryQueue" for the reply
>>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS Client.
>>>>
>>>>
>>>> PS: As Rabih stated before, we are using the same connection and same
>>>> session to create the JMSProducer for the request and the JMSConsumer for
>>>> the reply.
>>>>
>>>>
>>>> Exception
>>>> -------------------
>>>> javax.jms.IllegalStateException: The MessageConsumer was closed due to
>>>> an unrecoverable error.
>>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
>>>> eConsumer.java:330)
>>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
>>>> sumer.java:196)
>>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>>>> ssorImpl.java:62)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>>> thodAccessorImpl.java:43)
>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
>>>> Caused by: javax.jms.JMSException: No route to the destination node
>>>> [condition = qd:no-route-to-dest]
>>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>>>> tion(AmqpSupport.java:150)
>>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>>>> tion(AmqpSupport.java:105)
>>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
>>>> elyClosed(AmqpAbstractResource.java:147)
>>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
>>>> ssRemoteClose(AmqpAbstractResource.java:251)
>>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
>>>> s(AmqpProvider.java:795)
>>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
>>>> mqpProvider.java:90)
>>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
>>>> ovider.java:699)
>>>> at java.util.concurrent.Executors$RunnableAdapter.call(
>>>> Executors.java:511)
>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>>> Executor.java:1142)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>>> lExecutor.java:617)
>>>> at java.lang.Thread.run(Thread.java:745)
>>>>
>>>>
>>>> -------------------
>>>> Dispatch Router (PN_TRACE_FRM=1)
>>>> -------------------
>>>>
>>>> [832220]: <- SASL
>>>> [832220]: -> SASL
>>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
>>>> MBOL[:ANONYMOUS]]
>>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
>>>> initial-response=b"", hostname="host-name"]
>>>> [832220]:0 -> @sasl-outcome(68) [code=0]
>>>> [832220]: <- AMQP
>>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-a334-44c3-954a-2dd910161411:1",
>>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
>>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
>>>> L[:"sole-connection-for-container"], properties={:product="QpidJMS",
>>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
>>>> Corporation, OS: Windows 7, 6.1, amd64"}]
>>>> [832220]: -> AMQP
>>>> [832220]:0 -> @open(16) [container-id="router.10200",
>>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
>>>> offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router",
>>>> :version="0.7.0"}]
>>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>>>> outgoing-window=2147483647, handle-max=65535]
>>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
>>>> incoming-window=61, outgoing-window=2147483647]
>>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>>>> outgoing-window=2147483647, handle-max=65535]
>>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
>>>> incoming-window=61, outgoing-window=2147483647]
>>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
>>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
>>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
>>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]],
>>>> target=@target(41) [address="$management", durable=0,
>>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
>>>> initial-delivery-count=0]
>>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
>>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
>>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list",
>>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
>>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]],
>>>> initial-delivery-count=0, max-message-size=0]
>>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
>>>> link-credit=250, drain=false]
>>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
>>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
>>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [],
>>>> target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0,
>>>> dynamic=true, dynamic-node-properties={:"lif
>>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"temporary-queue"]],
>>>> incomplete-unsettled=false, initial-delivery-count=0]
>>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
>>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0, role=true,
>>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
>>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
>>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
>>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []},
>>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], initial-delivery-count=0,
>>>> max-message-size=0]
>>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
>>>> link-credit=250, drain=false]
>>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
>>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=true,
>>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [durable=0,
>>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
>>>> default-outcome=@modified(39) [delivery-failed=true],
>>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
>>>> :"amqp:released:list", :"amqp:modified:list"],
>>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41) []]
>>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
>>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=false,
>>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
>>>> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0,
>>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
>>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
>>>> [condition=:"qd:no-route-to-dest", description="No route to the
>>>> destination node"]]
>>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
>>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"0",
>>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
>>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
>>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
>>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
>>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
>>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
>>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
>>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
>>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
>>>> x04addr\xa1\x0dbrokerMachine"
>>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
>>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1,
>>>> link-credit=250, drain=false]
>>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
>>>> settled=true, state=@accepted(36) []]
>>>> [832220]:0 <- @close(24) []
>>>> [832220]: <- EOS
>>>> [832220]:0 -> @close(24) []
>>>> [832220]: -> EOS
>>>> Closed x.x.x.x:8961
>>>> Unexpected poll events: 0020 on x.x.x.x:8961
>>>> Unexpected poll events: 0020 on x.x.x.x:8961
>>>>
>>>> ------------------
>>>> JMS Client (PN_TRACE_FRM=1)
>>>> ------------------
>>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-4a22-9b22-69d27a017a83:1',
>>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
>>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
>>>> offeredCapabilities=null, desiredCapabilities=[sole-connection-for-container],
>>>> properties={product=QpidJMS, version=0.11.1, platform=JVM: 1.8.0_111,
>>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
>>>> [1244186219:0] <- Open{ containerId='router.10200', hostname='null',
>>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
>>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[ANONYMOUS-RELAY],
>>>> desiredCapabilities=null, properties={product=qpid-dispatch-router,
>>>> version=0.7.0}}
>>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
>>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
>>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
>>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
>>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
>>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
>>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>>> source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1',
>>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>>>> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list],
>>>> capabilities=null}, target=Target{address='$management', durable=NONE,
>>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
>>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
>>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>>> source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1',
>>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>>>> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list],
>>>> capabilities=null}, target=Target{address='$management', durable=NONE,
>>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
>>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0,
>>>> linkCredit=250, available=null, drain=false, echo=false, properties=null}
>>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
>>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>>> distributionMode=null, filter=null, defaultOutcome=null, outcomes=null,
>>>> capabilities=null}, target=Target{address='null', durable=NONE,
>>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>>>> capabilities=[temporary-queue]}, unsettled=null,
>>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
>>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>>> distributionMode=null, filter=null, defaultOutcome=null, outcomes=null,
>>>> capabilities=null}, target=Target{address='null', durable=NONE,
>>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>>>> capabilities=[temporary-queue]}, unsettled=null,
>>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
>>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0,
>>>> linkCredit=250, available=null, drain=false, echo=false, properties=null}
>>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
>>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>>> source=Source{address='null', durable=NONE, expiryPolicy=LINK_DETACH,
>>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>>> distributionMode=null, filter=null, defaultOutcome=Modified{deliveryFailed=true,
>>>> undeliverableHere=null, messageAnnotations=null},
>>>> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list,
>>>> amqp:modified:list], capabilities=[temporary-queue]},
>>>> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>>> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
>>>> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
>>>> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
>>>> properties=null}
>>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
>>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>>> distributionMode=null, filter=null, defaultOutcome=null, outcomes=null,
>>>> capabilities=null}, target=Target{address='null', durable=NONE,
>>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
>>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
>>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:1] <- Detach{handle=1, closed=true,
>>>> error=Error{condition=qd:no-route-to-dest, description='No route to the
>>>> destination node', info=null}}
>>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
>>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
>>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null, state=null,
>>>> resume=false, aborted=false, batchable=false} (312)
>>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
>>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
>>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@
>>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
>>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
>>>> apache.qpid.dispatch.connector\xa1\x09operation\
>>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
>>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
>>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
>>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
>>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=1,
>>>> linkCredit=250, available=null, drain=false, echo=false, properties=null}
>>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
>>>> settled=true, state=Accepted{}, batchable=false}
>>>> [1244186219:0] -> Close{error=null}
>>>> [1244186219:0] <- Close{error=null}
>>>>
>>>> Regards,
>>>>
>>>> Adel
>>>>
>>>> ________________________________
>>>> From: Robbie Gemmell <ro...@gmail.com>
>>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
>>>> To: users@qpid.apache.org
>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>>>
>>>> That looks fine at first glance. Its possible there is an issue in
>>>> there needing looked it. I am travelling this week so may not get to
>>>> look until afterwards, but will try to give things a look at. If you
>>>> could give more detail on the exception and maybe a protocol trace
>>>> that might be useful.
>>>>
>>>> Robbie
>>>>
>>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
>>>>
>>>>> Hello Robbie,
>>>>>
>>>>> Thanks for you for your answer.
>>>>> I will try the solutions you proposed.
>>>>>
>>>>> I need just need one clarification. Concerning the Jms, I already tried
>>>>> to
>>>>> use a temporary queue but it didn't work. May be i am using it wrong.
>>>>> Here
>>>>> is what i did:
>>>>>
>>>>> ...
>>>>> Session session = connection.createSession(false,
>>>>> Session.AUTO_ACKNOWLEDGE);
>>>>> Queue queue = session.createQueue("$management");
>>>>> MessageProducer producer = session.createProducer(queue);
>>>>>
>>>>> Queue tempDest = session.createTemporaryQueue();
>>>>> MessageConsumer responseConsumer = session.createConsumer(tempDest);
>>>>> connection.start();
>>>>>
>>>>> ObjectMessage objectMessage = session.createObjectMessage();
>>>>> objectMessage.setJMSReplyTo(tempDest);
>>>>> //fill the rest of the parameters ...
>>>>> producer.send(objectMessage);
>>>>> ObjectMessage replyMessage = (ObjectMessage)
>>>>> responseConsumer.receive(1000);
>>>>> ...
>>>>>
>>>>> I was getting an exception on the .receive() from the dispatch router
>>>>> saying that the reply-to address is bad...
>>>>> Should i create the temporary queue and the consumer from a different
>>>>> session then the producer?
>>>>>
>>>>> Best regards,
>>>>> Rabih
>>>>>
>>>>>
>>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
>>>>> robbie.gemmell@gmail.com>
>>>>> wrote:
>>>>>
>>>>> The session.createTemporaryQueue(); method is how JMS creates
>>>>>> temporary destinations for use in reply-to scenarios. The dispatch
>>>>>> tools will be doing essentially the same thing under the covers for
>>>>>> theirs.
>>>>>>
>>>>>> Both work by creating a 'dynamic' link attachment, with the server
>>>>>> returning an address for the dynamic attach to the client. One key
>>>>>> difference is with JMS you create the temporary destination (for which
>>>>>> the client uses a dynamic sender link to create), then separately
>>>>>> create a receiver using it (and in turn the address associated with
>>>>>> it), whereas non-JMS client/tools will typically just create a single
>>>>>> dynamic receiver link and use its address for the reply-to.
>>>>>>
>>>>>> For proton-j, there aren't any examples for this, but you you
>>>>>> essentially would change the link opening to not specify an address,
>>>>>> and instead set the source(for a receiver) or target (for a sender) to
>>>>>> be 'dynamic'. You would then inspect the remoteSource or remoteTarget
>>>>>> once the link had been reemotely attached, and get its
>>>>>> (server-generated) address, then use this as your reply-to.
>>>>>>
>>>>>> Robbie
>>>>>>
>>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like you
>>>>>>> suggested, it worked.
>>>>>>> But I cheated a little to make it work because I did not find a way in
>>>>>>>
>>>>>> JMS
>>>>>>
>>>>>>> to create a local queue. So I created a queue on the qpid-dispatch and
>>>>>>>
>>>>>> read
>>>>>>
>>>>>>> the result from it. You can check the attached code.
>>>>>>>
>>>>>>> Is there any way using qpid-jms to create a local queue on the client
>>>>>>>
>>>>>> side
>>>>>>
>>>>>>> to serve as a reply to address?
>>>>>>>
>>>>>>> For the proton-j test, I have the same question as above. I saw that
>>>>>>> it
>>>>>>>
>>>>>> can
>>>>>>
>>>>>>> be done with the C++ API. Are there any examples for proton-j or
>>>>>>>
>>>>>> something
>>>>>>
>>>>>>> that can help me?
>>>>>>>
>>>>>>> I saw may be in proton we don't need a local queue, may be we can get
>>>>>>> the
>>>>>>> address of the consumer directly and pass it in reply-to field. Is it
>>>>>>> correct?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rabih
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
>>>>>>> rob.j.godfrey@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>
>>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
>>>>>>>>>> To: users@qpid.apache.org
>>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
>>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>>>>>>>>>
>>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you told
>>>>>>>>>>>>
>>>>>>>>>>> me
>>>>>>
>>>>>>> Robbie and it worked.
>>>>>>>>>>>>
>>>>>>>>>>>> But like the proton-j case, the connector is not being created on
>>>>>>>>>>>> the
>>>>>>>>>>>> Qpid-dispatch side.
>>>>>>>>>>>> I attached the amqp communication into this mail.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The last frame in that file is incomplete (the previous error
>>>>>>>>>>>
>>>>>>>>>> regarding the
>>>>>>>>>
>>>>>>>>>> map body may or may not be a wireshark issue),but that last frame
>>>>>>>>>>>
>>>>>>>>>> is
>>>>>>
>>>>>>> likely
>>>>>>>>>
>>>>>>>>>> the response which would indicate the success or otherwise of the
>>>>>>>>>>>
>>>>>>>>>> frame. Is
>>>>>>>>>
>>>>>>>>>> there anything logged by the router?
>>>>>>>>>>>
>>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is simpler
>>>>>>>>>>> for
>>>>>>>>>>>
>>>>>>>>>> this
>>>>>>>>>
>>>>>>>>>> sort of thing in my view.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> As Gordon suggests, the proton trace logs might be more helpful.
>>>>>>>>>> You
>>>>>>>>>> can also do that with proton-j, and this the JMS client too since
>>>>>>>>>> it
>>>>>>>>>> uses proton-j.
>>>>>>>>>>
>>>>>>>>>> One key difference from the qdmanage case is you are not setting a
>>>>>>>>>> reply-to value or correlation-id to use along with it. I don't know
>>>>>>>>>>
>>>>>>>>> if
>>>>>>
>>>>>>> the router cares about not being able to send a response or not
>>>>>>>>>> though, but it might.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You could add the following to your dispatch router conf file
>>>>>>>>> (qdrouterd.conf) and restart the router (This will enable trace
>>>>>>>>>
>>>>>>>> logging)
>>>>>>
>>>>>>>
>>>>>>>>> log {
>>>>>>>>> module: DEFAULT
>>>>>>>>> enable: trace+
>>>>>>>>> output: /path/to/log/qdrouterd.log
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> When you run your management request, you will see proton frame
>>>>>>>>> trace
>>>>>>>>> and
>>>>>>>>> you will see additional logging out of the dispatch Python agent -
>>>>>>>>> something like the following -
>>>>>>>>>
>>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>>>>>>>>> Message(address=None,
>>>>>>>>> properties={'operation': 'CREATE', 'type':
>>>>>>>>> 'org.apache.qpid.dispatch.connector',
>>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
>>>>>>>>>
>>>>>>>> 'rabih.connector'},
>>>>>>
>>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>>>>>>>>> correlation_id=1L)
>>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>>>>>>>>> broker-machine:5673 proto=any, role=route-container
>>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
>>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector,
>>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>>>>>>>>> name=rabih.connector, port=5673, role=route-container,
>>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
>>>>>>>>> verifyHostName=True)
>>>>>>>>>
>>>>>>>>> The Python management agent will not process your request if there
>>>>>>>>> is
>>>>>>>>>
>>>>>>>> no
>>>>>>
>>>>>>> reply_to as seen here -
>>>>>>>>>
>>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
>>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Can I ask why the agent doesn't process the request? Just because
>>>>>>>> there
>>>>>>>> is
>>>>>>>> a reply-to doesn't mean that the sender will be around to actually
>>>>>>>> hear
>>>>>>>> the
>>>>>>>> reply, so it seems a bit arbitrary to say that because we *know* the
>>>>>>>> sender
>>>>>>>> won't learn of the outcome that we won't do anything... The spec
>>>>>>>> draft
>>>>>>>> doesn't currently say anything about this (obviously it should do),
>>>>>>>> but
>>>>>>>>
>>>>>>> my
>>>>>>
>>>>>>> expectation would certainly be that a request would be processed even
>>>>>>>> if
>>>>>>>> the replyTo address was not present (or ended up not routing
>>>>>>>> anywhere).
>>>>>>>> This is also how the Qpid Broker for Java implements this case.
>>>>>>>>
>>>>>>>> -- Rob
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Robbie
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>> ---------
>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Rob Godfrey <ro...@gmail.com>.
On 6 February 2017 at 18:44, Ted Ross <tr...@redhat.com> wrote:
> It seems odd that the client creates a _sender_ to the temporary queue
> that it will never send messages _to_ but will receive messages _from_.
>
>
This is because JMS semantics require the temporary node to have a lifetime
scoped to the session (not a link), so the JMS client has to create a
synthetic link which it uses simply to manage the lifetime of the dynamic
node. In order to not cause unintentional assigning of messages to a link
that will never actually be used for consumption, a sending link is used.
Note that in general JMS would expect that you should be able to send to a
temporary queue created in this way (since the point of temporary queues is
to use as a reply to)
> Anyway, when the client creates a receiver with a dynamic source (and no
> dynamic-node-properties), the router will accept the link and assign a
> temporary address as the source. This is only useful in this use case if
> the broker has a way of knowing that the temporary address is reachable via
> the router network.
>
> There is a way to route dynamic termini to a broker. If an
> x-opt-qd.address property is included in the dynamic-node-properties, this
> address will be used to route the attach to the broker. I've never tested
> this with a dynamic target in a sender. It might not work.
And this really isn't something you'd be expecting a generic client (like
the JMS client) to know :-)
-- Rob
>
>
> -Ted
>
>
> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
>
>> I've had a look at this. It would seem that Dispatch doesn't like what
>> the client is doing for createTemporaryQueue, but doesn't fail in a
>> very nice way, and the client then doesnt notice that things have gone
>> south in a somewhat unexpected way.
>>
>> The client opens a sending link with 'dynamic' target in order to
>> create a dynamic node for use as a TemporaryQueue address/destination
>> object, which specific consumers/producers are then created against by
>> the application. Dispatch doesn't seem to like that but erroneously
>> attaches the link 'successfully', though doesnt set a target address
>> as is expected. The client then doesnt notice this happened (its
>> checking for the link being refused, which it wasn't), allowing the
>> application to proceed as far as creating consumers/procuers using the
>> TemporaryQueue object, with creation of the e.g Consumer then failing
>> since the attach doesnt contain the needed information and leads to
>> Dispatch detaching it with the error (though it again doesnt actually
>> indicate its refusing the link during the attach response, as it
>> probably should have in this case).
>>
>> Making the client detect the current failure and having it throw an
>> aexception from createTemporaryQueue is simple enough.
>>
>> Hacking the client to use a dynamic recieving link instead, an address
>> was returned by Dispatch in the attach response as expected, however a
>> consumer on the resulting TemporaryQueue object using this address
>> still didnt get the message I sent to the same place. If I also gave
>> some credit on the link backing the TemporaryQeueue object itself then
>> that link gets sent the message by Dispatch, though this of no use for
>> the JMS client.
>>
>> Needs some more investigation, and I'll need to discuss with some
>> folks more familiar with Dispatch.
>>
>> Robbie
>>
>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com> wrote:
>>
>>> Hello Robbie,
>>>
>>>
>>> I replaced the "createQueue" with "createTemporaryQueue" for the reply
>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS Client.
>>>
>>>
>>> PS: As Rabih stated before, we are using the same connection and same
>>> session to create the JMSProducer for the request and the JMSConsumer for
>>> the reply.
>>>
>>>
>>> Exception
>>> -------------------
>>> javax.jms.IllegalStateException: The MessageConsumer was closed due to
>>> an unrecoverable error.
>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
>>> eConsumer.java:330)
>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
>>> sumer.java:196)
>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>>> ssorImpl.java:62)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>> thodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
>>> Caused by: javax.jms.JMSException: No route to the destination node
>>> [condition = qd:no-route-to-dest]
>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>>> tion(AmqpSupport.java:150)
>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
>>> tion(AmqpSupport.java:105)
>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
>>> elyClosed(AmqpAbstractResource.java:147)
>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
>>> ssRemoteClose(AmqpAbstractResource.java:251)
>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
>>> s(AmqpProvider.java:795)
>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(A
>>> mqpProvider.java:90)
>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpPr
>>> ovider.java:699)
>>> at java.util.concurrent.Executors$RunnableAdapter.call(
>>> Executors.java:511)
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>>> tureTask.run(ScheduledThreadPoolExecutor.java:293)
>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>> Executor.java:1142)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>> lExecutor.java:617)
>>> at java.lang.Thread.run(Thread.java:745)
>>>
>>>
>>> -------------------
>>> Dispatch Router (PN_TRACE_FRM=1)
>>> -------------------
>>>
>>> [832220]: <- SASL
>>> [832220]: -> SASL
>>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
>>> MBOL[:ANONYMOUS]]
>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
>>> initial-response=b"", hostname="host-name"]
>>> [832220]:0 -> @sasl-outcome(68) [code=0]
>>> [832220]: <- AMQP
>>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-a334-44c3-954a-2dd910161411:1",
>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
>>> idle-time-out=30000, desired-capabilities=@PN_SYMBO
>>> L[:"sole-connection-for-container"], properties={:product="QpidJMS",
>>> :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle
>>> Corporation, OS: Windows 7, 6.1, amd64"}]
>>> [832220]: -> AMQP
>>> [832220]:0 -> @open(16) [container-id="router.10200",
>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
>>> offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router",
>>> :version="0.7.0"}]
>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>>> outgoing-window=2147483647, handle-max=65535]
>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
>>> incoming-window=61, outgoing-window=2147483647]
>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>>> outgoing-window=2147483647, handle-max=65535]
>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
>>> incoming-window=61, outgoing-window=2147483647]
>>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec7
>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]],
>>> target=@target(41) [address="$management", durable=0,
>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
>>> initial-delivery-count=0]
>>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec7
>>> 55cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>>> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
>>> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list",
>>> :"amqp:rejected:list"]], target=@target(41) [address="$management",
>>> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]],
>>> initial-delivery-count=0, max-message-size=0]
>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
>>> link-credit=250, drain=false]
>>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-cre
>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
>>> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [],
>>> target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0,
>>> dynamic=true, dynamic-node-properties={:"lif
>>> etime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"temporary-queue"]],
>>> incomplete-unsettled=false, initial-delivery-count=0]
>>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-cre
>>> ator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0, role=true,
>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
>>> timeout=0, dynamic=false], target=@target(41) [durable=0,
>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []},
>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], initial-delivery-count=0,
>>> max-message-size=0]
>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
>>> link-credit=250, drain=false]
>>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8e
>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=true,
>>> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [durable=0,
>>> expiry-policy=:"link-detach", timeout=0, dynamic=false,
>>> default-outcome=@modified(39) [delivery-failed=true],
>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
>>> :"amqp:released:list", :"amqp:modified:list"],
>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41) []]
>>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8e
>>> c755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=false,
>>> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
>>> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0,
>>> dynamic=false], initial-delivery-count=0, max-message-size=0]
>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
>>> [condition=:"qd:no-route-to-dest", description="No route to the
>>> destination node"]]
>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"0",
>>> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1
>>> )\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-
>>> typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-
>>> f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\
>>> x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.
>>> connector\xa1\x04type\xa1"org.apache.qpid.dispatch.
>>> connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\
>>> xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\
>>> x04port\xa1\x04name\xa1\x0frabih.connector\xa1\
>>> x04addr\xa1\x0dbrokerMachine"
>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1,
>>> link-credit=250, drain=false]
>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
>>> settled=true, state=@accepted(36) []]
>>> [832220]:0 <- @close(24) []
>>> [832220]: <- EOS
>>> [832220]:0 -> @close(24) []
>>> [832220]: -> EOS
>>> Closed x.x.x.x:8961
>>> Unexpected poll events: 0020 on x.x.x.x:8961
>>> Unexpected poll events: 0020 on x.x.x.x:8961
>>>
>>> ------------------
>>> JMS Client (PN_TRACE_FRM=1)
>>> ------------------
>>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-4a22-9b22-69d27a017a83:1',
>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
>>> offeredCapabilities=null, desiredCapabilities=[sole-connection-for-container],
>>> properties={product=QpidJMS, version=0.11.1, platform=JVM: 1.8.0_111,
>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
>>> [1244186219:0] <- Open{ containerId='router.10200', hostname='null',
>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
>>> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[ANONYMOUS-RELAY],
>>> desiredCapabilities=null, properties={product=qpid-dispatch-router,
>>> version=0.7.0}}
>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:1] -> Attach{name='qpid-jms:sender:I
>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>> source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1',
>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>>> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list],
>>> capabilities=null}, target=Target{address='$management', durable=NONE,
>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:1] <- Attach{name='qpid-jms:sender:I
>>> D:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>> source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1',
>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>>> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list],
>>> capabilities=null}, target=Target{address='$management', durable=NONE,
>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0,
>>> linkCredit=250, available=null, drain=false, echo=false, properties=null}
>>> [1244186219:0] -> Attach{name='qpid-jms:temp-que
>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>>> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>> distributionMode=null, filter=null, defaultOutcome=null, outcomes=null,
>>> capabilities=null}, target=Target{address='null', durable=NONE,
>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>>> capabilities=[temporary-queue]}, unsettled=null,
>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>> distributionMode=null, filter=null, defaultOutcome=null, outcomes=null,
>>> capabilities=null}, target=Target{address='null', durable=NONE,
>>> expiryPolicy=LINK_DETACH, timeout=0, dynamic=true,
>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>>> capabilities=[temporary-queue]}, unsettled=null,
>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0,
>>> linkCredit=250, available=null, drain=false, echo=false, properties=null}
>>> [1244186219:1] -> Attach{name='qpid-jms:receiver
>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>>> role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>> source=Source{address='null', durable=NONE, expiryPolicy=LINK_DETACH,
>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>> distributionMode=null, filter=null, defaultOutcome=Modified{deliveryFailed=true,
>>> undeliverableHere=null, messageAnnotations=null},
>>> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list,
>>> amqp:modified:list], capabilities=[temporary-queue]},
>>> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
>>> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
>>> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
>>> properties=null}
>>> [1244186219:1] <- Attach{name='qpid-jms:receiver
>>> :ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1,
>>> role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
>>> distributionMode=null, filter=null, defaultOutcome=null, outcomes=null,
>>> capabilities=null}, target=Target{address='null', durable=NONE,
>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:1] <- Detach{handle=1, closed=true,
>>> error=Error{condition=qd:no-route-to-dest, description='No route to the
>>> destination node', info=null}}
>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null, state=null,
>>> resume=false, aborted=false, batchable=false} (312)
>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\
>>> x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/
>>> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@
>>> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
>>> x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
>>> apache.qpid.dispatch.connector\xa1\x09operation\
>>> xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
>>> container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\
>>> x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=1,
>>> linkCredit=250, available=null, drain=false, echo=false, properties=null}
>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
>>> settled=true, state=Accepted{}, batchable=false}
>>> [1244186219:0] -> Close{error=null}
>>> [1244186219:0] <- Close{error=null}
>>>
>>> Regards,
>>>
>>> Adel
>>>
>>> ________________________________
>>> From: Robbie Gemmell <ro...@gmail.com>
>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
>>> To: users@qpid.apache.org
>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>>
>>> That looks fine at first glance. Its possible there is an issue in
>>> there needing looked it. I am travelling this week so may not get to
>>> look until afterwards, but will try to give things a look at. If you
>>> could give more detail on the exception and maybe a protocol trace
>>> that might be useful.
>>>
>>> Robbie
>>>
>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
>>>
>>>> Hello Robbie,
>>>>
>>>> Thanks for you for your answer.
>>>> I will try the solutions you proposed.
>>>>
>>>> I need just need one clarification. Concerning the Jms, I already tried
>>>> to
>>>> use a temporary queue but it didn't work. May be i am using it wrong.
>>>> Here
>>>> is what i did:
>>>>
>>>> ...
>>>> Session session = connection.createSession(false,
>>>> Session.AUTO_ACKNOWLEDGE);
>>>> Queue queue = session.createQueue("$management");
>>>> MessageProducer producer = session.createProducer(queue);
>>>>
>>>> Queue tempDest = session.createTemporaryQueue();
>>>> MessageConsumer responseConsumer = session.createConsumer(tempDest);
>>>> connection.start();
>>>>
>>>> ObjectMessage objectMessage = session.createObjectMessage();
>>>> objectMessage.setJMSReplyTo(tempDest);
>>>> //fill the rest of the parameters ...
>>>> producer.send(objectMessage);
>>>> ObjectMessage replyMessage = (ObjectMessage)
>>>> responseConsumer.receive(1000);
>>>> ...
>>>>
>>>> I was getting an exception on the .receive() from the dispatch router
>>>> saying that the reply-to address is bad...
>>>> Should i create the temporary queue and the consumer from a different
>>>> session then the producer?
>>>>
>>>> Best regards,
>>>> Rabih
>>>>
>>>>
>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
>>>> robbie.gemmell@gmail.com>
>>>> wrote:
>>>>
>>>> The session.createTemporaryQueue(); method is how JMS creates
>>>>> temporary destinations for use in reply-to scenarios. The dispatch
>>>>> tools will be doing essentially the same thing under the covers for
>>>>> theirs.
>>>>>
>>>>> Both work by creating a 'dynamic' link attachment, with the server
>>>>> returning an address for the dynamic attach to the client. One key
>>>>> difference is with JMS you create the temporary destination (for which
>>>>> the client uses a dynamic sender link to create), then separately
>>>>> create a receiver using it (and in turn the address associated with
>>>>> it), whereas non-JMS client/tools will typically just create a single
>>>>> dynamic receiver link and use its address for the reply-to.
>>>>>
>>>>> For proton-j, there aren't any examples for this, but you you
>>>>> essentially would change the link opening to not specify an address,
>>>>> and instead set the source(for a receiver) or target (for a sender) to
>>>>> be 'dynamic'. You would then inspect the remoteSource or remoteTarget
>>>>> once the link had been reemotely attached, and get its
>>>>> (server-generated) address, then use this as your reply-to.
>>>>>
>>>>> Robbie
>>>>>
>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like you
>>>>>> suggested, it worked.
>>>>>> But I cheated a little to make it work because I did not find a way in
>>>>>>
>>>>> JMS
>>>>>
>>>>>> to create a local queue. So I created a queue on the qpid-dispatch and
>>>>>>
>>>>> read
>>>>>
>>>>>> the result from it. You can check the attached code.
>>>>>>
>>>>>> Is there any way using qpid-jms to create a local queue on the client
>>>>>>
>>>>> side
>>>>>
>>>>>> to serve as a reply to address?
>>>>>>
>>>>>> For the proton-j test, I have the same question as above. I saw that
>>>>>> it
>>>>>>
>>>>> can
>>>>>
>>>>>> be done with the C++ API. Are there any examples for proton-j or
>>>>>>
>>>>> something
>>>>>
>>>>>> that can help me?
>>>>>>
>>>>>> I saw may be in proton we don't need a local queue, may be we can get
>>>>>> the
>>>>>> address of the consumer directly and pass it in reply-to field. Is it
>>>>>> correct?
>>>>>>
>>>>>> Thanks,
>>>>>> Rabih
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
>>>>>> rob.j.godfrey@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>
>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
>>>>>>>>> To: users@qpid.apache.org
>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>>>>>>>>
>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you told
>>>>>>>>>>>
>>>>>>>>>> me
>>>>>
>>>>>> Robbie and it worked.
>>>>>>>>>>>
>>>>>>>>>>> But like the proton-j case, the connector is not being created on
>>>>>>>>>>> the
>>>>>>>>>>> Qpid-dispatch side.
>>>>>>>>>>> I attached the amqp communication into this mail.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The last frame in that file is incomplete (the previous error
>>>>>>>>>>
>>>>>>>>> regarding the
>>>>>>>>
>>>>>>>>> map body may or may not be a wireshark issue),but that last frame
>>>>>>>>>>
>>>>>>>>> is
>>>>>
>>>>>> likely
>>>>>>>>
>>>>>>>>> the response which would indicate the success or otherwise of the
>>>>>>>>>>
>>>>>>>>> frame. Is
>>>>>>>>
>>>>>>>>> there anything logged by the router?
>>>>>>>>>>
>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is simpler
>>>>>>>>>> for
>>>>>>>>>>
>>>>>>>>> this
>>>>>>>>
>>>>>>>>> sort of thing in my view.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> As Gordon suggests, the proton trace logs might be more helpful.
>>>>>>>>> You
>>>>>>>>> can also do that with proton-j, and this the JMS client too since
>>>>>>>>> it
>>>>>>>>> uses proton-j.
>>>>>>>>>
>>>>>>>>> One key difference from the qdmanage case is you are not setting a
>>>>>>>>> reply-to value or correlation-id to use along with it. I don't know
>>>>>>>>>
>>>>>>>> if
>>>>>
>>>>>> the router cares about not being able to send a response or not
>>>>>>>>> though, but it might.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You could add the following to your dispatch router conf file
>>>>>>>> (qdrouterd.conf) and restart the router (This will enable trace
>>>>>>>>
>>>>>>> logging)
>>>>>
>>>>>>
>>>>>>>> log {
>>>>>>>> module: DEFAULT
>>>>>>>> enable: trace+
>>>>>>>> output: /path/to/log/qdrouterd.log
>>>>>>>> }
>>>>>>>>
>>>>>>>> When you run your management request, you will see proton frame
>>>>>>>> trace
>>>>>>>> and
>>>>>>>> you will see additional logging out of the dispatch Python agent -
>>>>>>>> something like the following -
>>>>>>>>
>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>>>>>>>> Message(address=None,
>>>>>>>> properties={'operation': 'CREATE', 'type':
>>>>>>>> 'org.apache.qpid.dispatch.connector',
>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
>>>>>>>>
>>>>>>> 'rabih.connector'},
>>>>>
>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>>>>>>>> correlation_id=1L)
>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>>>>>>>> broker-machine:5673 proto=any, role=route-container
>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector,
>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>>>>>>>> name=rabih.connector, port=5673, role=route-container,
>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
>>>>>>>> verifyHostName=True)
>>>>>>>>
>>>>>>>> The Python management agent will not process your request if there
>>>>>>>> is
>>>>>>>>
>>>>>>> no
>>>>>
>>>>>> reply_to as seen here -
>>>>>>>>
>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Can I ask why the agent doesn't process the request? Just because
>>>>>>> there
>>>>>>> is
>>>>>>> a reply-to doesn't mean that the sender will be around to actually
>>>>>>> hear
>>>>>>> the
>>>>>>> reply, so it seems a bit arbitrary to say that because we *know* the
>>>>>>> sender
>>>>>>> won't learn of the outcome that we won't do anything... The spec
>>>>>>> draft
>>>>>>> doesn't currently say anything about this (obviously it should do),
>>>>>>> but
>>>>>>>
>>>>>> my
>>>>>
>>>>>> expectation would certainly be that a request would be processed even
>>>>>>> if
>>>>>>> the replyTo address was not present (or ended up not routing
>>>>>>> anywhere).
>>>>>>> This is also how the Qpid Broker for Java implements this case.
>>>>>>>
>>>>>>> -- Rob
>>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Robbie
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>
>>>>>>>> ---------
>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Robbie Gemmell <ro...@gmail.com>.
On 6 February 2017 at 17:44, Ted Ross <tr...@redhat.com> wrote:
> It seems odd that the client creates a _sender_ to the temporary queue that
> it will never send messages _to_ but will receive messages _from_.
>
It does this because it would never receive messages on this link
either, and it seemed less confusing to have a sender, and makes the
actual receiver(s) of the messages on that connection more easily
identified. The creating link is only used to create the node, nothing
else, as in JMS createTemporaryQueue etc is an explicit operation on a
session which returns a named destination object (which may be
explicitly deleted), entirely separate from creating
producers/consumers for it which is only done later.
> Anyway, when the client creates a receiver with a dynamic source (and no
> dynamic-node-properties), the router will accept the link and assign a
> temporary address as the source. This is only useful in this use case if
> the broker has a way of knowing that the temporary address is reachable via
> the router network.
>
> There is a way to route dynamic termini to a broker. If an x-opt-qd.address
> property is included in the dynamic-node-properties, this address will be
> used to route the attach to the broker. I've never tested this with a
> dynamic target in a sender. It might not work.
>
> -Ted
>
In this case its the router which was being attempted to be managed,
not a broker, and just trying to use createTemporaryQueue to get an
address for the responses.
>
> On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
>>
>> I've had a look at this. It would seem that Dispatch doesn't like what
>> the client is doing for createTemporaryQueue, but doesn't fail in a
>> very nice way, and the client then doesnt notice that things have gone
>> south in a somewhat unexpected way.
>>
>> The client opens a sending link with 'dynamic' target in order to
>> create a dynamic node for use as a TemporaryQueue address/destination
>> object, which specific consumers/producers are then created against by
>> the application. Dispatch doesn't seem to like that but erroneously
>> attaches the link 'successfully', though doesnt set a target address
>> as is expected. The client then doesnt notice this happened (its
>> checking for the link being refused, which it wasn't), allowing the
>> application to proceed as far as creating consumers/procuers using the
>> TemporaryQueue object, with creation of the e.g Consumer then failing
>> since the attach doesnt contain the needed information and leads to
>> Dispatch detaching it with the error (though it again doesnt actually
>> indicate its refusing the link during the attach response, as it
>> probably should have in this case).
>>
>> Making the client detect the current failure and having it throw an
>> aexception from createTemporaryQueue is simple enough.
>>
>> Hacking the client to use a dynamic recieving link instead, an address
>> was returned by Dispatch in the attach response as expected, however a
>> consumer on the resulting TemporaryQueue object using this address
>> still didnt get the message I sent to the same place. If I also gave
>> some credit on the link backing the TemporaryQeueue object itself then
>> that link gets sent the message by Dispatch, though this of no use for
>> the JMS client.
>>
>> Needs some more investigation, and I'll need to discuss with some
>> folks more familiar with Dispatch.
>>
>> Robbie
>>
>> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com> wrote:
>>>
>>> Hello Robbie,
>>>
>>>
>>> I replaced the "createQueue" with "createTemporaryQueue" for the reply
>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS Client.
>>>
>>>
>>> PS: As Rabih stated before, we are using the same connection and same
>>> session to create the JMSProducer for the request and the JMSConsumer for
>>> the reply.
>>>
>>>
>>> Exception
>>> -------------------
>>> javax.jms.IllegalStateException: The MessageConsumer was closed due to an
>>> unrecoverable error.
>>> at
>>> org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessageConsumer.java:330)
>>> at
>>> org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageConsumer.java:196)
>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
>>> Caused by: javax.jms.JMSException: No route to the destination node
>>> [condition = qd:no-route-to-dest]
>>> at
>>> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:150)
>>> at
>>> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:105)
>>> at
>>> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remotelyClosed(AmqpAbstractResource.java:147)
>>> at
>>> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:251)
>>> at
>>> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:795)
>>> at
>>> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:90)
>>> at
>>> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:699)
>>> at
>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>> at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>> at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>> at java.lang.Thread.run(Thread.java:745)
>>>
>>>
>>> -------------------
>>> Dispatch Router (PN_TRACE_FRM=1)
>>> -------------------
>>>
>>> [832220]: <- SASL
>>> [832220]: -> SASL
>>> [832220]:0 -> @sasl-mechanisms(64)
>>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
>>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b"",
>>> hostname="host-name"]
>>> [832220]:0 -> @sasl-outcome(68) [code=0]
>>> [832220]: <- AMQP
>>> [832220]:0 <- @open(16)
>>> [container-id="ID:9d96ddb8-a334-44c3-954a-2dd910161411:1",
>>> hostname="host-name", max-frame-size=1048576, channel-max=32767,
>>> idle-time-out=30000,
>>> desired-capabilities=@PN_SYMBOL[:"sole-connection-for-container"],
>>> properties={:product="QpidJMS", :version="0.11.1", :platform="JVM:
>>> 1.8.0_111, 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64"}]
>>> [832220]: -> AMQP
>>> [832220]:0 -> @open(16) [container-id="router.10200",
>>> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
>>> offered-capabilities=:"ANONYMOUS-RELAY",
>>> properties={:product="qpid-dispatch-router", :version="0.7.0"}]
>>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>>> outgoing-window=2147483647, handle-max=65535]
>>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
>>> incoming-window=61, outgoing-window=2147483647]
>>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
>>> outgoing-window=2147483647, handle-max=65535]
>>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
>>> incoming-window=61, outgoing-window=2147483647]
>>> [832220]:1 <- @attach(18)
>>> [name="qpid-jms:sender:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management",
>>> handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0,
>>> source=@source(40) [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
>>> durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false,
>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]],
>>> target=@target(41) [address="$management", durable=0,
>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>>> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
>>> initial-delivery-count=0]
>>> [832220]:1 -> @attach(18)
>>> [name="qpid-jms:sender:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management",
>>> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
>>> source=@source(40) [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1",
>>> durable=0, timeout=0, dynamic=false,
>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]],
>>> target=@target(41) [address="$management", durable=0, timeout=0,
>>> dynamic=false, capabilities=@PN_SYMBOL[:queue]], initial-delivery-count=0,
>>> max-message-size=0]
>>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
>>> link-credit=250, drain=false]
>>> [832220]:0 <- @attach(18)
>>> [name="qpid-jms:temp-queue-creator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1",
>>> handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0,
>>> source=@source(40) [], target=@target(41) [durable=0,
>>> expiry-policy=:"link-detach", timeout=0, dynamic=true,
>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []},
>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], incomplete-unsettled=false,
>>> initial-delivery-count=0]
>>> [832220]:0 -> @attach(18)
>>> [name="qpid-jms:temp-queue-creator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1",
>>> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
>>> source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41)
>>> [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=true,
>>> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []},
>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], initial-delivery-count=0,
>>> max-message-size=0]
>>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
>>> link-credit=250, drain=false]
>>> [832220]:1 <- @attach(18)
>>> [name="qpid-jms:receiver:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null",
>>> handle=1, role=true, snd-settle-mode=0, rcv-settle-mode=0,
>>> source=@source(40) [durable=0, expiry-policy=:"link-detach", timeout=0,
>>> dynamic=false, default-outcome=@modified(39) [delivery-failed=true],
>>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
>>> :"amqp:released:list", :"amqp:modified:list"],
>>> capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41) []]
>>> [832220]:1 -> @attach(18)
>>> [name="qpid-jms:receiver:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null",
>>> handle=1, role=false, snd-settle-mode=2, rcv-settle-mode=0,
>>> source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41)
>>> [durable=0, timeout=0, dynamic=false], initial-delivery-count=0,
>>> max-message-size=0]
>>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
>>> [condition=:"qd:no-route-to-dest", description="No route to the destination
>>> node"]]
>>> [832220]:1 <- @detach(22) [handle=1, closed=true]
>>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"0",
>>> message-format=0] (312)
>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.dispatch.connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
>>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
>>> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1,
>>> link-credit=250, drain=false]
>>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0, settled=true,
>>> state=@accepted(36) []]
>>> [832220]:0 <- @close(24) []
>>> [832220]: <- EOS
>>> [832220]:0 -> @close(24) []
>>> [832220]: -> EOS
>>> Closed x.x.x.x:8961
>>> Unexpected poll events: 0020 on x.x.x.x:8961
>>> Unexpected poll events: 0020 on x.x.x.x:8961
>>>
>>> ------------------
>>> JMS Client (PN_TRACE_FRM=1)
>>> ------------------
>>> [1244186219:0] -> Open{
>>> containerId='ID:da8ce84a-c69b-4a22-9b22-69d27a017a83:1',
>>> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
>>> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
>>> offeredCapabilities=null,
>>> desiredCapabilities=[sole-connection-for-container],
>>> properties={product=QpidJMS, version=0.11.1, platform=JVM: 1.8.0_111,
>>> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
>>> [1244186219:0] <- Open{ containerId='router.10200', hostname='null',
>>> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
>>> outgoingLocales=null, incomingLocales=null,
>>> offeredCapabilities=[ANONYMOUS-RELAY], desiredCapabilities=null,
>>> properties={product=qpid-dispatch-router, version=0.7.0}}
>>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
>>> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
>>> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:1] ->
>>> Attach{name='qpid-jms:sender:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
>>> handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>> source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1',
>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>>> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list],
>>> capabilities=null}, target=Target{address='$management', durable=NONE,
>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:1] <-
>>> Attach{name='qpid-jms:sender:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management',
>>> handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>> source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1',
>>> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> dynamicNodeProperties=null, distributionMode=null, filter=null,
>>> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list],
>>> capabilities=null}, target=Target{address='$management', durable=NONE,
>>> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
>>> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
>>> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0,
>>> linkCredit=250, available=null, drain=false, echo=false, properties=null}
>>> [1244186219:0] ->
>>> Attach{name='qpid-jms:temp-queue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1',
>>> handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
>>> filter=null, defaultOutcome=null, outcomes=null, capabilities=null},
>>> target=Target{address='null', durable=NONE, expiryPolicy=LINK_DETACH,
>>> timeout=0, dynamic=true,
>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>>> capabilities=[temporary-queue]}, unsettled=null, incompleteUnsettled=false,
>>> initialDeliveryCount=0, maxMessageSize=null, offeredCapabilities=null,
>>> desiredCapabilities=null, properties=null}
>>> [1244186219:0] <-
>>> Attach{name='qpid-jms:temp-queue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1',
>>> handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
>>> filter=null, defaultOutcome=null, outcomes=null, capabilities=null},
>>> target=Target{address='null', durable=NONE, expiryPolicy=LINK_DETACH,
>>> timeout=0, dynamic=true,
>>> dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},
>>> capabilities=[temporary-queue]}, unsettled=null, incompleteUnsettled=false,
>>> initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null,
>>> desiredCapabilities=null, properties=null}
>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0,
>>> linkCredit=250, available=null, drain=false, echo=false, properties=null}
>>> [1244186219:1] ->
>>> Attach{name='qpid-jms:receiver:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null',
>>> handle=1, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
>>> source=Source{address='null', durable=NONE, expiryPolicy=LINK_DETACH,
>>> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
>>> filter=null, defaultOutcome=Modified{deliveryFailed=true,
>>> undeliverableHere=null, messageAnnotations=null},
>>> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list,
>>> amqp:modified:list], capabilities=[temporary-queue]},
>>> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
>>> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
>>> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
>>> properties=null}
>>> [1244186219:1] <-
>>> Attach{name='qpid-jms:receiver:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null',
>>> handle=1, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
>>> filter=null, defaultOutcome=null, outcomes=null, capabilities=null},
>>> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
>>> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
>>> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
>>> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
>>> properties=null}
>>> [1244186219:1] <- Detach{handle=1, closed=true,
>>> error=Error{condition=qd:no-route-to-dest, description='No route to the
>>> destination node', info=null}}
>>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
>>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
>>> messageFormat=0, settled=null, more=false, rcvSettleMode=null, state=null,
>>> resume=false, aborted=false, batchable=false} (312)
>>> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.dispatch.connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
>>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=1,
>>> linkCredit=250, available=null, drain=false, echo=false, properties=null}
>>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
>>> settled=true, state=Accepted{}, batchable=false}
>>> [1244186219:0] -> Close{error=null}
>>> [1244186219:0] <- Close{error=null}
>>>
>>> Regards,
>>>
>>> Adel
>>>
>>> ________________________________
>>> From: Robbie Gemmell <ro...@gmail.com>
>>> Sent: Tuesday, January 24, 2017 7:33:32 PM
>>> To: users@qpid.apache.org
>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>>
>>> That looks fine at first glance. Its possible there is an issue in
>>> there needing looked it. I am travelling this week so may not get to
>>> look until afterwards, but will try to give things a look at. If you
>>> could give more detail on the exception and maybe a protocol trace
>>> that might be useful.
>>>
>>> Robbie
>>>
>>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
>>>>
>>>> Hello Robbie,
>>>>
>>>> Thanks for you for your answer.
>>>> I will try the solutions you proposed.
>>>>
>>>> I need just need one clarification. Concerning the Jms, I already tried
>>>> to
>>>> use a temporary queue but it didn't work. May be i am using it wrong.
>>>> Here
>>>> is what i did:
>>>>
>>>> ...
>>>> Session session = connection.createSession(false,
>>>> Session.AUTO_ACKNOWLEDGE);
>>>> Queue queue = session.createQueue("$management");
>>>> MessageProducer producer = session.createProducer(queue);
>>>>
>>>> Queue tempDest = session.createTemporaryQueue();
>>>> MessageConsumer responseConsumer = session.createConsumer(tempDest);
>>>> connection.start();
>>>>
>>>> ObjectMessage objectMessage = session.createObjectMessage();
>>>> objectMessage.setJMSReplyTo(tempDest);
>>>> //fill the rest of the parameters ...
>>>> producer.send(objectMessage);
>>>> ObjectMessage replyMessage = (ObjectMessage)
>>>> responseConsumer.receive(1000);
>>>> ...
>>>>
>>>> I was getting an exception on the .receive() from the dispatch router
>>>> saying that the reply-to address is bad...
>>>> Should i create the temporary queue and the consumer from a different
>>>> session then the producer?
>>>>
>>>> Best regards,
>>>> Rabih
>>>>
>>>>
>>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell
>>>> <ro...@gmail.com>
>>>> wrote:
>>>>
>>>>> The session.createTemporaryQueue(); method is how JMS creates
>>>>> temporary destinations for use in reply-to scenarios. The dispatch
>>>>> tools will be doing essentially the same thing under the covers for
>>>>> theirs.
>>>>>
>>>>> Both work by creating a 'dynamic' link attachment, with the server
>>>>> returning an address for the dynamic attach to the client. One key
>>>>> difference is with JMS you create the temporary destination (for which
>>>>> the client uses a dynamic sender link to create), then separately
>>>>> create a receiver using it (and in turn the address associated with
>>>>> it), whereas non-JMS client/tools will typically just create a single
>>>>> dynamic receiver link and use its address for the reply-to.
>>>>>
>>>>> For proton-j, there aren't any examples for this, but you you
>>>>> essentially would change the link opening to not specify an address,
>>>>> and instead set the source(for a receiver) or target (for a sender) to
>>>>> be 'dynamic'. You would then inspect the remoteSource or remoteTarget
>>>>> once the link had been reemotely attached, and get its
>>>>> (server-generated) address, then use this as your reply-to.
>>>>>
>>>>> Robbie
>>>>>
>>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like you
>>>>>> suggested, it worked.
>>>>>> But I cheated a little to make it work because I did not find a way in
>>>>>
>>>>> JMS
>>>>>>
>>>>>> to create a local queue. So I created a queue on the qpid-dispatch and
>>>>>
>>>>> read
>>>>>>
>>>>>> the result from it. You can check the attached code.
>>>>>>
>>>>>> Is there any way using qpid-jms to create a local queue on the client
>>>>>
>>>>> side
>>>>>>
>>>>>> to serve as a reply to address?
>>>>>>
>>>>>> For the proton-j test, I have the same question as above. I saw that
>>>>>> it
>>>>>
>>>>> can
>>>>>>
>>>>>> be done with the C++ API. Are there any examples for proton-j or
>>>>>
>>>>> something
>>>>>>
>>>>>> that can help me?
>>>>>>
>>>>>> I saw may be in proton we don't need a local queue, may be we can get
>>>>>> the
>>>>>> address of the consumer directly and pass it in reply-to field. Is it
>>>>>> correct?
>>>>>>
>>>>>> Thanks,
>>>>>> Rabih
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey
>>>>>> <ro...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>>
>>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
>>>>>>>>> To: users@qpid.apache.org
>>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
>>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>>>>>>>>
>>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I inserted the map directly into the ObjectMessage like you told
>>>>>
>>>>> me
>>>>>>>>>>>
>>>>>>>>>>> Robbie and it worked.
>>>>>>>>>>>
>>>>>>>>>>> But like the proton-j case, the connector is not being created on
>>>>>>>>>>> the
>>>>>>>>>>> Qpid-dispatch side.
>>>>>>>>>>> I attached the amqp communication into this mail.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The last frame in that file is incomplete (the previous error
>>>>>>>>
>>>>>>>> regarding the
>>>>>>>>>>
>>>>>>>>>> map body may or may not be a wireshark issue),but that last frame
>>>>>
>>>>> is
>>>>>>>>
>>>>>>>> likely
>>>>>>>>>>
>>>>>>>>>> the response which would indicate the success or otherwise of the
>>>>>>>>
>>>>>>>> frame. Is
>>>>>>>>>>
>>>>>>>>>> there anything logged by the router?
>>>>>>>>>>
>>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is simpler
>>>>>>>>>> for
>>>>>>>>
>>>>>>>> this
>>>>>>>>>>
>>>>>>>>>> sort of thing in my view.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As Gordon suggests, the proton trace logs might be more helpful.
>>>>>>>>> You
>>>>>>>>> can also do that with proton-j, and this the JMS client too since
>>>>>>>>> it
>>>>>>>>> uses proton-j.
>>>>>>>>>
>>>>>>>>> One key difference from the qdmanage case is you are not setting a
>>>>>>>>> reply-to value or correlation-id to use along with it. I don't know
>>>>>
>>>>> if
>>>>>>>>>
>>>>>>>>> the router cares about not being able to send a response or not
>>>>>>>>> though, but it might.
>>>>>>>>
>>>>>>>>
>>>>>>>> You could add the following to your dispatch router conf file
>>>>>>>> (qdrouterd.conf) and restart the router (This will enable trace
>>>>>
>>>>> logging)
>>>>>>>>
>>>>>>>>
>>>>>>>> log {
>>>>>>>> module: DEFAULT
>>>>>>>> enable: trace+
>>>>>>>> output: /path/to/log/qdrouterd.log
>>>>>>>> }
>>>>>>>>
>>>>>>>> When you run your management request, you will see proton frame
>>>>>>>> trace
>>>>>>>> and
>>>>>>>> you will see additional logging out of the dispatch Python agent -
>>>>>>>> something like the following -
>>>>>>>>
>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>>>>>>>> Message(address=None,
>>>>>>>> properties={'operation': 'CREATE', 'type':
>>>>>>>> 'org.apache.qpid.dispatch.connector',
>>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
>>>>>
>>>>> 'rabih.connector'},
>>>>>>>>
>>>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>>>>>>>> correlation_id=1L)
>>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>>>>>>>> broker-machine:5673 proto=any, role=route-container
>>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
>>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector,
>>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>>>>>>>> name=rabih.connector, port=5673, role=route-container,
>>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
>>>>>>>> verifyHostName=True)
>>>>>>>>
>>>>>>>> The Python management agent will not process your request if there
>>>>>>>> is
>>>>>
>>>>> no
>>>>>>>>
>>>>>>>> reply_to as seen here -
>>>>>>>>
>>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
>>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Can I ask why the agent doesn't process the request? Just because
>>>>>>> there
>>>>>>> is
>>>>>>> a reply-to doesn't mean that the sender will be around to actually
>>>>>>> hear
>>>>>>> the
>>>>>>> reply, so it seems a bit arbitrary to say that because we *know* the
>>>>>>> sender
>>>>>>> won't learn of the outcome that we won't do anything... The spec
>>>>>>> draft
>>>>>>> doesn't currently say anything about this (obviously it should do),
>>>>>>> but
>>>>>
>>>>> my
>>>>>>>
>>>>>>> expectation would certainly be that a request would be processed even
>>>>>>> if
>>>>>>> the replyTo address was not present (or ended up not routing
>>>>>>> anywhere).
>>>>>>> This is also how the Qpid Broker for Java implements this case.
>>>>>>>
>>>>>>> -- Rob
>>>>>>>
>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Robbie
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>
>>>>> ---------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Ted Ross <tr...@redhat.com>.
It seems odd that the client creates a _sender_ to the temporary queue
that it will never send messages _to_ but will receive messages _from_.
Anyway, when the client creates a receiver with a dynamic source (and no
dynamic-node-properties), the router will accept the link and assign a
temporary address as the source. This is only useful in this use case
if the broker has a way of knowing that the temporary address is
reachable via the router network.
There is a way to route dynamic termini to a broker. If an
x-opt-qd.address property is included in the dynamic-node-properties,
this address will be used to route the attach to the broker. I've never
tested this with a dynamic target in a sender. It might not work.
-Ted
On 02/01/2017 11:07 AM, Robbie Gemmell wrote:
> I've had a look at this. It would seem that Dispatch doesn't like what
> the client is doing for createTemporaryQueue, but doesn't fail in a
> very nice way, and the client then doesnt notice that things have gone
> south in a somewhat unexpected way.
>
> The client opens a sending link with 'dynamic' target in order to
> create a dynamic node for use as a TemporaryQueue address/destination
> object, which specific consumers/producers are then created against by
> the application. Dispatch doesn't seem to like that but erroneously
> attaches the link 'successfully', though doesnt set a target address
> as is expected. The client then doesnt notice this happened (its
> checking for the link being refused, which it wasn't), allowing the
> application to proceed as far as creating consumers/procuers using the
> TemporaryQueue object, with creation of the e.g Consumer then failing
> since the attach doesnt contain the needed information and leads to
> Dispatch detaching it with the error (though it again doesnt actually
> indicate its refusing the link during the attach response, as it
> probably should have in this case).
>
> Making the client detect the current failure and having it throw an
> aexception from createTemporaryQueue is simple enough.
>
> Hacking the client to use a dynamic recieving link instead, an address
> was returned by Dispatch in the attach response as expected, however a
> consumer on the resulting TemporaryQueue object using this address
> still didnt get the message I sent to the same place. If I also gave
> some credit on the link backing the TemporaryQeueue object itself then
> that link gets sent the message by Dispatch, though this of no use for
> the JMS client.
>
> Needs some more investigation, and I'll need to discuss with some
> folks more familiar with Dispatch.
>
> Robbie
>
> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com> wrote:
>> Hello Robbie,
>>
>>
>> I replaced the "createQueue" with "createTemporaryQueue" for the reply consumer and activated PN_TRACE_FRM on Dispatch Router and JMS Client.
>>
>>
>> PS: As Rabih stated before, we are using the same connection and same session to create the JMSProducer for the request and the JMSConsumer for the reply.
>>
>>
>> Exception
>> -------------------
>> javax.jms.IllegalStateException: The MessageConsumer was closed due to an unrecoverable error.
>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessageConsumer.java:330)
>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageConsumer.java:196)
>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
>> Caused by: javax.jms.JMSException: No route to the destination node [condition = qd:no-route-to-dest]
>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:150)
>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:105)
>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remotelyClosed(AmqpAbstractResource.java:147)
>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:251)
>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:795)
>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:90)
>> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:699)
>> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> at java.lang.Thread.run(Thread.java:745)
>>
>>
>> -------------------
>> Dispatch Router (PN_TRACE_FRM=1)
>> -------------------
>>
>> [832220]: <- SASL
>> [832220]: -> SASL
>> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
>> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b"", hostname="host-name"]
>> [832220]:0 -> @sasl-outcome(68) [code=0]
>> [832220]: <- AMQP
>> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-a334-44c3-954a-2dd910161411:1", hostname="host-name", max-frame-size=1048576, channel-max=32767, idle-time-out=30000, desired-capabilities=@PN_SYMBOL[:"sole-connection-for-container"], properties={:product="QpidJMS", :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64"}]
>> [832220]: -> AMQP
>> [832220]:0 -> @open(16) [container-id="router.10200", max-frame-size=16384, channel-max=32767, idle-time-out=8000, offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router", :version="0.7.0"}]
>> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047, outgoing-window=2147483647, handle-max=65535]
>> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=61, outgoing-window=2147483647]
>> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047, outgoing-window=2147483647, handle-max=65535]
>> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0, incoming-window=61, outgoing-window=2147483647]
>> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]], target=@target(41) [address="$management", durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false, initial-delivery-count=0]
>> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0, timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]], target=@target(41) [address="$management", durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]], initial-delivery-count=0, max-message-size=0]
>> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=250, drain=false]
>> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-creator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [], target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=true, dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"temporary-queue"]], incomplete-unsettled=false, initial-delivery-count=0]
>> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-creator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=true, dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"temporary-queue"]], initial-delivery-count=0, max-message-size=0]
>> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=250, drain=false]
>> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=true, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, default-outcome=@modified(39) [delivery-failed=true], outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list", :"amqp:released:list", :"amqp:modified:list"], capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41) []]
>> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
>> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29) [condition=:"qd:no-route-to-dest", description="No route to the destination node"]]
>> [832220]:1 <- @detach(22) [handle=1, closed=true]
>> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"0", message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.dispatch.connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
>> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1, link-credit=250, drain=false]
>> [832220]:1 -> @disposition(21) [role=true, first=0, last=0, settled=true, state=@accepted(36) []]
>> [832220]:0 <- @close(24) []
>> [832220]: <- EOS
>> [832220]:0 -> @close(24) []
>> [832220]: -> EOS
>> Closed x.x.x.x:8961
>> Unexpected poll events: 0020 on x.x.x.x:8961
>> Unexpected poll events: 0020 on x.x.x.x:8961
>>
>> ------------------
>> JMS Client (PN_TRACE_FRM=1)
>> ------------------
>> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-4a22-9b22-69d27a017a83:1', hostname='host-name', maxFrameSize=1048576, channelMax=32767, idleTimeOut=30000, outgoingLocales=null, incomingLocales=null, offeredCapabilities=null, desiredCapabilities=[sole-connection-for-container], properties={product=QpidJMS, version=0.11.1, platform=JVM: 1.8.0_111, 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
>> [1244186219:0] <- Open{ containerId='router.10200', hostname='null', maxFrameSize=16384, channelMax=32767, idleTimeOut=8000, outgoingLocales=null, incomingLocales=null, offeredCapabilities=[ANONYMOUS-RELAY], desiredCapabilities=null, properties={product=qpid-dispatch-router, version=0.7.0}}
>> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1, incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535, offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295, offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1, incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535, offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0, incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295, offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> [1244186219:1] -> Attach{name='qpid-jms:sender:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list], capabilities=null}, target=Target{address='$management', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> [1244186219:1] <- Attach{name='qpid-jms:sender:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list], capabilities=null}, target=Target{address='$management', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61, nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0, linkCredit=250, available=null, drain=false, echo=false, properties=null}
>> [1244186219:0] -> Attach{name='qpid-jms:temp-queue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, target=Target{address='null', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0, dynamic=true, dynamicNodeProperties={lifetime-policy=DeleteOnClose{}}, capabilities=[temporary-queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> [1244186219:0] <- Attach{name='qpid-jms:temp-queue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, target=Target{address='null', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0, dynamic=true, dynamicNodeProperties={lifetime-policy=DeleteOnClose{}}, capabilities=[temporary-queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61, nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0, linkCredit=250, available=null, drain=false, echo=false, properties=null}
>> [1244186219:1] -> Attach{name='qpid-jms:receiver:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=Modified{deliveryFailed=true, undeliverableHere=null, messageAnnotations=null}, outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, amqp:modified:list], capabilities=[temporary-queue]}, target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> [1244186219:1] <- Attach{name='qpid-jms:receiver:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, properties=null}
>> [1244186219:1] <- Detach{handle=1, closed=true, error=Error{condition=qd:no-route-to-dest, description='No route to the destination node', info=null}}
>> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
>> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0, messageFormat=0, settled=null, more=false, rcvSettleMode=null, state=null, resume=false, aborted=false, batchable=false} (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.dispatch.connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
>> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61, nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=1, linkCredit=250, available=null, drain=false, echo=false, properties=null}
>> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0, settled=true, state=Accepted{}, batchable=false}
>> [1244186219:0] -> Close{error=null}
>> [1244186219:0] <- Close{error=null}
>>
>> Regards,
>>
>> Adel
>>
>> ________________________________
>> From: Robbie Gemmell <ro...@gmail.com>
>> Sent: Tuesday, January 24, 2017 7:33:32 PM
>> To: users@qpid.apache.org
>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>
>> That looks fine at first glance. Its possible there is an issue in
>> there needing looked it. I am travelling this week so may not get to
>> look until afterwards, but will try to give things a look at. If you
>> could give more detail on the exception and maybe a protocol trace
>> that might be useful.
>>
>> Robbie
>>
>> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
>>> Hello Robbie,
>>>
>>> Thanks for you for your answer.
>>> I will try the solutions you proposed.
>>>
>>> I need just need one clarification. Concerning the Jms, I already tried to
>>> use a temporary queue but it didn't work. May be i am using it wrong. Here
>>> is what i did:
>>>
>>> ...
>>> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
>>> Queue queue = session.createQueue("$management");
>>> MessageProducer producer = session.createProducer(queue);
>>>
>>> Queue tempDest = session.createTemporaryQueue();
>>> MessageConsumer responseConsumer = session.createConsumer(tempDest);
>>> connection.start();
>>>
>>> ObjectMessage objectMessage = session.createObjectMessage();
>>> objectMessage.setJMSReplyTo(tempDest);
>>> //fill the rest of the parameters ...
>>> producer.send(objectMessage);
>>> ObjectMessage replyMessage = (ObjectMessage) responseConsumer.receive(1000);
>>> ...
>>>
>>> I was getting an exception on the .receive() from the dispatch router
>>> saying that the reply-to address is bad...
>>> Should i create the temporary queue and the consumer from a different
>>> session then the producer?
>>>
>>> Best regards,
>>> Rabih
>>>
>>>
>>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <ro...@gmail.com>
>>> wrote:
>>>
>>>> The session.createTemporaryQueue(); method is how JMS creates
>>>> temporary destinations for use in reply-to scenarios. The dispatch
>>>> tools will be doing essentially the same thing under the covers for
>>>> theirs.
>>>>
>>>> Both work by creating a 'dynamic' link attachment, with the server
>>>> returning an address for the dynamic attach to the client. One key
>>>> difference is with JMS you create the temporary destination (for which
>>>> the client uses a dynamic sender link to create), then separately
>>>> create a receiver using it (and in turn the address associated with
>>>> it), whereas non-JMS client/tools will typically just create a single
>>>> dynamic receiver link and use its address for the reply-to.
>>>>
>>>> For proton-j, there aren't any examples for this, but you you
>>>> essentially would change the link opening to not specify an address,
>>>> and instead set the source(for a receiver) or target (for a sender) to
>>>> be 'dynamic'. You would then inspect the remoteSource or remoteTarget
>>>> once the link had been reemotely attached, and get its
>>>> (server-generated) address, then use this as your reply-to.
>>>>
>>>> Robbie
>>>>
>>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com> wrote:
>>>>> Hello,
>>>>>
>>>>> When I added to the JMS test the ".setJMSReplyTo()" queue, like you
>>>>> suggested, it worked.
>>>>> But I cheated a little to make it work because I did not find a way in
>>>> JMS
>>>>> to create a local queue. So I created a queue on the qpid-dispatch and
>>>> read
>>>>> the result from it. You can check the attached code.
>>>>>
>>>>> Is there any way using qpid-jms to create a local queue on the client
>>>> side
>>>>> to serve as a reply to address?
>>>>>
>>>>> For the proton-j test, I have the same question as above. I saw that it
>>>> can
>>>>> be done with the C++ API. Are there any examples for proton-j or
>>>> something
>>>>> that can help me?
>>>>>
>>>>> I saw may be in proton we don't need a local queue, may be we can get the
>>>>> address of the consumer directly and pass it in reply-to field. Is it
>>>>> correct?
>>>>>
>>>>> Thanks,
>>>>> Rabih
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <ro...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Robbie Gemmell" <ro...@gmail.com>
>>>>>>>> To: users@qpid.apache.org
>>>>>>>> Sent: Friday, January 20, 2017 2:18:45 PM
>>>>>>>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>>>>>>>
>>>>>>>> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
>>>>>>>>> On 20/01/17 18:40, Rabih M wrote:
>>>>>>>>>>
>>>>>>>>>> I inserted the map directly into the ObjectMessage like you told
>>>> me
>>>>>>>>>> Robbie and it worked.
>>>>>>>>>>
>>>>>>>>>> But like the proton-j case, the connector is not being created on
>>>>>>>>>> the
>>>>>>>>>> Qpid-dispatch side.
>>>>>>>>>> I attached the amqp communication into this mail.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The last frame in that file is incomplete (the previous error
>>>>>>> regarding the
>>>>>>>>> map body may or may not be a wireshark issue),but that last frame
>>>> is
>>>>>>> likely
>>>>>>>>> the response which would indicate the success or otherwise of the
>>>>>>> frame. Is
>>>>>>>>> there anything logged by the router?
>>>>>>>>>
>>>>>>>>> If you can, just running the router with PN_TRACE_FRM=1 is simpler
>>>>>>>>> for
>>>>>>> this
>>>>>>>>> sort of thing in my view.
>>>>>>>>>
>>>>>>>>
>>>>>>>> As Gordon suggests, the proton trace logs might be more helpful. You
>>>>>>>> can also do that with proton-j, and this the JMS client too since it
>>>>>>>> uses proton-j.
>>>>>>>>
>>>>>>>> One key difference from the qdmanage case is you are not setting a
>>>>>>>> reply-to value or correlation-id to use along with it. I don't know
>>>> if
>>>>>>>> the router cares about not being able to send a response or not
>>>>>>>> though, but it might.
>>>>>>>
>>>>>>> You could add the following to your dispatch router conf file
>>>>>>> (qdrouterd.conf) and restart the router (This will enable trace
>>>> logging)
>>>>>>>
>>>>>>> log {
>>>>>>> module: DEFAULT
>>>>>>> enable: trace+
>>>>>>> output: /path/to/log/qdrouterd.log
>>>>>>> }
>>>>>>>
>>>>>>> When you run your management request, you will see proton frame trace
>>>>>>> and
>>>>>>> you will see additional logging out of the dispatch Python agent -
>>>>>>> something like the following -
>>>>>>>
>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>>>>>>> Message(address=None,
>>>>>>> properties={'operation': 'CREATE', 'type':
>>>>>>> 'org.apache.qpid.dispatch.connector',
>>>>>>> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>>>>>>> 'route-container', 'addr': 'broker-machine', 'name':
>>>> 'rabih.connector'},
>>>>>>> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>>>>>>> correlation_id=1L)
>>>>>>> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>>>>>>> broker-machine:5673 proto=any, role=route-container
>>>>>>> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>>>>>>> ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
>>>>>>> host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector,
>>>>>>> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>>>>>>> name=rabih.connector, port=5673, role=route-container,
>>>>>>> stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
>>>>>>> verifyHostName=True)
>>>>>>>
>>>>>>> The Python management agent will not process your request if there is
>>>> no
>>>>>>> reply_to as seen here -
>>>>>>>
>>>>>>> https://github.com/apache/qpid-dispatch/blob/master/
>>>>>>> python/qpid_dispatch_internal/management/agent.py#L822
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Can I ask why the agent doesn't process the request? Just because there
>>>>>> is
>>>>>> a reply-to doesn't mean that the sender will be around to actually hear
>>>>>> the
>>>>>> reply, so it seems a bit arbitrary to say that because we *know* the
>>>>>> sender
>>>>>> won't learn of the outcome that we won't do anything... The spec draft
>>>>>> doesn't currently say anything about this (obviously it should do), but
>>>> my
>>>>>> expectation would certainly be that a request would be processed even if
>>>>>> the replyTo address was not present (or ended up not routing anywhere).
>>>>>> This is also how the Qpid Broker for Java implements this case.
>>>>>>
>>>>>> -- Rob
>>>>>>
>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>>
>>>>>>>> Robbie
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>> ---------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Rob Godfrey <ro...@gmail.com>.
We will definitely be wanting to support AMQP management using the JMS
client. We are having a few discussions at the moment about more strictly
defining the requirements for management reply-tos/dynamic nodes and once
that is firmed up we would look to define a mechanism by which these can be
used from JMS. There's a lot of work on both AMQP Management and AMQP
Addressing that we'll (wearing my OASIS hat here) be kicking off in the
coming weeks.
Hope this helps,
Rob
On 1 February 2017 at 19:02, Adel Boutros <Ad...@live.com> wrote:
> Thanks Robbie for taking a look.
>
>
> We can live with a real queue for now. However from the whole discussion,
> it seems what we are doing using JMS is not officially supported.
>
> To what extent are you going to commit to this support?
>
> Would it be dropped soon? Would it be officialised soon?
>
>
> What we like about JMS is the procedural calls when compared to Proton's
> reactive API.
>
>
> Regards,
>
> Adel
>
> ________________________________
> From: Robbie Gemmell <ro...@gmail.com>
> Sent: Wednesday, February 1, 2017 5:07:02 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> I've had a look at this. It would seem that Dispatch doesn't like what
> the client is doing for createTemporaryQueue, but doesn't fail in a
> very nice way, and the client then doesnt notice that things have gone
> south in a somewhat unexpected way.
>
> The client opens a sending link with 'dynamic' target in order to
> create a dynamic node for use as a TemporaryQueue address/destination
> object, which specific consumers/producers are then created against by
> the application. Dispatch doesn't seem to like that but erroneously
> attaches the link 'successfully', though doesnt set a target address
> as is expected. The client then doesnt notice this happened (its
> checking for the link being refused, which it wasn't), allowing the
> application to proceed as far as creating consumers/procuers using the
> TemporaryQueue object, with creation of the e.g Consumer then failing
> since the attach doesnt contain the needed information and leads to
> Dispatch detaching it with the error (though it again doesnt actually
> indicate its refusing the link during the attach response, as it
> probably should have in this case).
>
> Making the client detect the current failure and having it throw an
> aexception from createTemporaryQueue is simple enough.
>
> Hacking the client to use a dynamic recieving link instead, an address
> was returned by Dispatch in the attach response as expected, however a
> consumer on the resulting TemporaryQueue object using this address
> still didnt get the message I sent to the same place. If I also gave
> some credit on the link backing the TemporaryQeueue object itself then
> that link gets sent the message by Dispatch, though this of no use for
> the JMS client.
>
> Needs some more investigation, and I'll need to discuss with some
> folks more familiar with Dispatch.
>
> Robbie
>
> On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com> wrote:
> > Hello Robbie,
> >
> >
> > I replaced the "createQueue" with "createTemporaryQueue" for the reply
> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS Client.
> >
> >
> > PS: As Rabih stated before, we are using the same connection and same
> session to create the JMSProducer for the request and the JMSConsumer for
> the reply.
> >
> >
> > Exception
> > -------------------
> > javax.jms.IllegalStateException: The MessageConsumer was closed due to
> an unrecoverable error.
> > at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(
> JmsMessageConsumer.java:330)
> > at org.apache.qpid.jms.JmsMessageConsumer.receive(
> JmsMessageConsumer.java:196)
> > at murex.messaging.client.JmsTest.main(JmsTest.java:57)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:498)
> > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> > Caused by: javax.jms.JMSException: No route to the destination node
> [condition = qd:no-route-to-dest]
> > at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(
> AmqpSupport.java:150)
> > at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(
> AmqpSupport.java:105)
> > at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.
> remotelyClosed(AmqpAbstractResource.java:147)
> > at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.
> processRemoteClose(AmqpAbstractResource.java:251)
> > at org.apache.qpid.jms.provider.amqp.AmqpProvider.
> processUpdates(AmqpProvider.java:795)
> > at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(
> AmqpProvider.java:90)
> > at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(
> AmqpProvider.java:699)
> > at java.util.concurrent.Executors$RunnableAdapter.
> call(Executors.java:511)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > at java.util.concurrent.ScheduledThreadPoolExecutor$
> ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> > at java.util.concurrent.ScheduledThreadPoolExecutor$
> ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> > at java.lang.Thread.run(Thread.java:745)
> >
> >
> > -------------------
> > Dispatch Router (PN_TRACE_FRM=1)
> > -------------------
> >
> > [832220]: <- SASL
> > [832220]: -> SASL
> > [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_
> SYMBOL[:ANONYMOUS]]
> > [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"", hostname="host-name"]
> > [832220]:0 -> @sasl-outcome(68) [code=0]
> > [832220]: <- AMQP
> > [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-
> a334-44c3-954a-2dd910161411:1", hostname="host-name",
> max-frame-size=1048576, channel-max=32767, idle-time-out=30000,
> desired-capabilities=@PN_SYMBOL[:"sole-connection-for-container"],
> properties={:product="QpidJMS", :version="0.11.1", :platform="JVM:
> 1.8.0_111, 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64"}]
> > [832220]: -> AMQP
> > [832220]:0 -> @open(16) [container-id="router.10200",
> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router",
> :version="0.7.0"}]
> > [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> outgoing-window=2147483647, handle-max=65535]
> > [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
> incoming-window=61, outgoing-window=2147483647]
> > [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047,
> outgoing-window=2147483647, handle-max=65535]
> > [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0,
> incoming-window=61, outgoing-window=2147483647]
> > [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:
> 8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
> expiry-policy=:"session-end", timeout=0, dynamic=false,
> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]],
> target=@target(41) [address="$management", durable=0,
> expiry-policy=:"session-end", timeout=0, dynamic=false,
> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
> initial-delivery-count=0]
> > [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:
> 8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0,
> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0,
> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list",
> :"amqp:rejected:list"]], target=@target(41) [address="$management",
> durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]],
> initial-delivery-count=0, max-message-size=0]
> > [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
> link-credit=250, drain=false]
> > [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-
> creator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [],
> target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0,
> dynamic=true, dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43)
> []}, capabilities=@PN_SYMBOL[:"temporary-queue"]],
> incomplete-unsettled=false, initial-delivery-count=0]
> > [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-
> creator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0,
> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0,
> expiry-policy=:"link-detach", timeout=0, dynamic=true,
> dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []},
> capabilities=@PN_SYMBOL[:"temporary-queue"]], initial-delivery-count=0,
> max-message-size=0]
> > [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61,
> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
> link-credit=250, drain=false]
> > [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:
> 8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=true,
> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [durable=0,
> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> default-outcome=@modified(39) [delivery-failed=true],
> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> :"amqp:released:list", :"amqp:modified:list"], capabilities=@PN_SYMBOL[:"temporary-queue"]],
> target=@target(41) []]
> > [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:
> 8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0, max-message-size=0]
> > [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29)
> [condition=:"qd:no-route-to-dest", description="No route to the
> destination node"]]
> > [832220]:1 <- @detach(22) [handle=1, closed=true]
> > [832220]:1 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"0",
> message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\
> xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-
> msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-
> 9f39-f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\
> x00\x00\x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\
> xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.
> dispatch.connector\xa1\x09operation\xa1\x06CREATE\
> x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-container\xa1\
> x04port\xa1\x04port\xa1\x04name\xa1\x0frabih.connector\xa1\x04addr\xa1\
> x0dbrokerMachine"
> > [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61,
> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1,
> link-credit=250, drain=false]
> > [832220]:1 -> @disposition(21) [role=true, first=0, last=0,
> settled=true, state=@accepted(36) []]
> > [832220]:0 <- @close(24) []
> > [832220]: <- EOS
> > [832220]:0 -> @close(24) []
> > [832220]: -> EOS
> > Closed x.x.x.x:8961
> > Unexpected poll events: 0020 on x.x.x.x:8961
> > Unexpected poll events: 0020 on x.x.x.x:8961
> >
> > ------------------
> > JMS Client (PN_TRACE_FRM=1)
> > ------------------
> > [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-4a22-9b22-69d27a017a83:1',
> hostname='host-name', maxFrameSize=1048576, channelMax=32767,
> idleTimeOut=30000, outgoingLocales=null, incomingLocales=null,
> offeredCapabilities=null, desiredCapabilities=[sole-connection-for-container],
> properties={product=QpidJMS, version=0.11.1, platform=JVM: 1.8.0_111,
> 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
> > [1244186219:0] <- Open{ containerId='router.10200', hostname='null',
> maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
> outgoingLocales=null, incomingLocales=null, offeredCapabilities=[ANONYMOUS-RELAY],
> desiredCapabilities=null, properties={product=qpid-dispatch-router,
> version=0.7.0}}
> > [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> > [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> > [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> > [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
> incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> > [1244186219:1] -> Attach{name='qpid-jms:sender:
> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
> role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list],
> capabilities=null}, target=Target{address='$management', durable=NONE,
> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> > [1244186219:1] <- Attach{name='qpid-jms:sender:
> ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0,
> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list],
> capabilities=null}, target=Target{address='$management', durable=NONE,
> expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
> incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> > [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61,
> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0,
> linkCredit=250, available=null, drain=false, echo=false, properties=null}
> > [1244186219:0] -> Attach{name='qpid-jms:temp-queue-creator:ID:53f2be62-
> ad72-4193-a824-3293ffc57168:1:1', handle=0, role=SENDER,
> sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=LINK_DETACH,
> timeout=0, dynamic=true, dynamicNodeProperties={
> lifetime-policy=DeleteOnClose{}}, capabilities=[temporary-queue]},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> > [1244186219:0] <- Attach{name='qpid-jms:temp-queue-creator:ID:53f2be62-
> ad72-4193-a824-3293ffc57168:1:1', handle=0, role=RECEIVER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=LINK_DETACH,
> timeout=0, dynamic=true, dynamicNodeProperties={
> lifetime-policy=DeleteOnClose{}}, capabilities=[temporary-queue]},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> > [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0,
> linkCredit=250, available=null, drain=false, echo=false, properties=null}
> > [1244186219:1] -> Attach{name='qpid-jms:receiver:ID:53f2be62-ad72-
> 4193-a824-3293ffc57168:1:1:1:null', handle=1, role=RECEIVER,
> sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='null',
> durable=NONE, expiryPolicy=LINK_DETACH, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=Modified{deliveryFailed=true, undeliverableHere=null,
> messageAnnotations=null}, outcomes=[amqp:accepted:list, amqp:rejected:list,
> amqp:released:list, amqp:modified:list], capabilities=[temporary-queue]},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> > [1244186219:1] <- Attach{name='qpid-jms:receiver:ID:53f2be62-ad72-
> 4193-a824-3293ffc57168:1:1:1:null', handle=1, role=SENDER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> > [1244186219:1] <- Detach{handle=1, closed=true,
> error=Error{condition=qd:no-route-to-dest, description='No route to the
> destination node', info=null}}
> > [1244186219:1] -> Detach{handle=1, closed=true, error=null}
> > [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
> messageFormat=0, settled=null, more=false, rcvSettleMode=null, state=null,
> resume=false, aborted=false, batchable=false} (312)
> "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-
> destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\
> xa1/ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@
> @@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\x06\xa1\x04name\
> xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.
> dispatch.connector\xa1\x09operation\xa1\x06CREATE\
> x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-container\xa1\
> x04port\xa1\x04port\xa1\x04name\xa1\x0frabih.connector\xa1\x04addr\xa1\
> x0dbrokerMachine"
> > [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61,
> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=1,
> linkCredit=250, available=null, drain=false, echo=false, properties=null}
> > [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0,
> settled=true, state=Accepted{}, batchable=false}
> > [1244186219:0] -> Close{error=null}
> > [1244186219:0] <- Close{error=null}
> >
> > Regards,
> >
> > Adel
> >
> > ________________________________
> > From: Robbie Gemmell <ro...@gmail.com>
> > Sent: Tuesday, January 24, 2017 7:33:32 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >
> > That looks fine at first glance. Its possible there is an issue in
> > there needing looked it. I am travelling this week so may not get to
> > look until afterwards, but will try to give things a look at. If you
> > could give more detail on the exception and maybe a protocol trace
> > that might be useful.
> >
> > Robbie
> >
> > On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
> >> Hello Robbie,
> >>
> >> Thanks for you for your answer.
> >> I will try the solutions you proposed.
> >>
> >> I need just need one clarification. Concerning the Jms, I already tried
> to
> >> use a temporary queue but it didn't work. May be i am using it wrong.
> Here
> >> is what i did:
> >>
> >> ...
> >> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> >> Queue queue = session.createQueue("$management");
> >> MessageProducer producer = session.createProducer(queue);
> >>
> >> Queue tempDest = session.createTemporaryQueue();
> >> MessageConsumer responseConsumer = session.createConsumer(tempDest);
> >> connection.start();
> >>
> >> ObjectMessage objectMessage = session.createObjectMessage();
> >> objectMessage.setJMSReplyTo(tempDest);
> >> //fill the rest of the parameters ...
> >> producer.send(objectMessage);
> >> ObjectMessage replyMessage = (ObjectMessage)
> responseConsumer.receive(1000);
> >> ...
> >>
> >> I was getting an exception on the .receive() from the dispatch router
> >> saying that the reply-to address is bad...
> >> Should i create the temporary queue and the consumer from a different
> >> session then the producer?
> >>
> >> Best regards,
> >> Rabih
> >>
> >>
> >> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <
> robbie.gemmell@gmail.com>
> >> wrote:
> >>
> >>> The session.createTemporaryQueue(); method is how JMS creates
> >>> temporary destinations for use in reply-to scenarios. The dispatch
> >>> tools will be doing essentially the same thing under the covers for
> >>> theirs.
> >>>
> >>> Both work by creating a 'dynamic' link attachment, with the server
> >>> returning an address for the dynamic attach to the client. One key
> >>> difference is with JMS you create the temporary destination (for which
> >>> the client uses a dynamic sender link to create), then separately
> >>> create a receiver using it (and in turn the address associated with
> >>> it), whereas non-JMS client/tools will typically just create a single
> >>> dynamic receiver link and use its address for the reply-to.
> >>>
> >>> For proton-j, there aren't any examples for this, but you you
> >>> essentially would change the link opening to not specify an address,
> >>> and instead set the source(for a receiver) or target (for a sender) to
> >>> be 'dynamic'. You would then inspect the remoteSource or remoteTarget
> >>> once the link had been reemotely attached, and get its
> >>> (server-generated) address, then use this as your reply-to.
> >>>
> >>> Robbie
> >>>
> >>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com> wrote:
> >>> > Hello,
> >>> >
> >>> > When I added to the JMS test the ".setJMSReplyTo()" queue, like you
> >>> > suggested, it worked.
> >>> > But I cheated a little to make it work because I did not find a way
> in
> >>> JMS
> >>> > to create a local queue. So I created a queue on the qpid-dispatch
> and
> >>> read
> >>> > the result from it. You can check the attached code.
> >>> >
> >>> > Is there any way using qpid-jms to create a local queue on the client
> >>> side
> >>> > to serve as a reply to address?
> >>> >
> >>> > For the proton-j test, I have the same question as above. I saw that
> it
> >>> can
> >>> > be done with the C++ API. Are there any examples for proton-j or
> >>> something
> >>> > that can help me?
> >>> >
> >>> > I saw may be in proton we don't need a local queue, may be we can
> get the
> >>> > address of the consumer directly and pass it in reply-to field. Is it
> >>> > correct?
> >>> >
> >>> > Thanks,
> >>> > Rabih
> >>> >
> >>> >
> >>> >
> >>> > On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <
> rob.j.godfrey@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com>
> wrote:
> >>> >>
> >>> >> >
> >>> >> >
> >>> >> > ----- Original Message -----
> >>> >> > > From: "Robbie Gemmell" <ro...@gmail.com>
> >>> >> > > To: users@qpid.apache.org
> >>> >> > > Sent: Friday, January 20, 2017 2:18:45 PM
> >>> >> > > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid
> Jms
> >>> >> > >
> >>> >> > > On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com>
> wrote:
> >>> >> > > > On 20/01/17 18:40, Rabih M wrote:
> >>> >> > > >>
> >>> >> > > >> I inserted the map directly into the ObjectMessage like you
> told
> >>> me
> >>> >> > > >> Robbie and it worked.
> >>> >> > > >>
> >>> >> > > >> But like the proton-j case, the connector is not being
> created on
> >>> >> > > >> the
> >>> >> > > >> Qpid-dispatch side.
> >>> >> > > >> I attached the amqp communication into this mail.
> >>> >> > > >
> >>> >> > > >
> >>> >> > > > The last frame in that file is incomplete (the previous error
> >>> >> > regarding the
> >>> >> > > > map body may or may not be a wireshark issue),but that last
> frame
> >>> is
> >>> >> > likely
> >>> >> > > > the response which would indicate the success or otherwise of
> the
> >>> >> > frame. Is
> >>> >> > > > there anything logged by the router?
> >>> >> > > >
> >>> >> > > > If you can, just running the router with PN_TRACE_FRM=1 is
> simpler
> >>> >> > > > for
> >>> >> > this
> >>> >> > > > sort of thing in my view.
> >>> >> > > >
> >>> >> > >
> >>> >> > > As Gordon suggests, the proton trace logs might be more
> helpful. You
> >>> >> > > can also do that with proton-j, and this the JMS client too
> since it
> >>> >> > > uses proton-j.
> >>> >> > >
> >>> >> > > One key difference from the qdmanage case is you are not
> setting a
> >>> >> > > reply-to value or correlation-id to use along with it. I don't
> know
> >>> if
> >>> >> > > the router cares about not being able to send a response or not
> >>> >> > > though, but it might.
> >>> >> >
> >>> >> > You could add the following to your dispatch router conf file
> >>> >> > (qdrouterd.conf) and restart the router (This will enable trace
> >>> logging)
> >>> >> >
> >>> >> > log {
> >>> >> > module: DEFAULT
> >>> >> > enable: trace+
> >>> >> > output: /path/to/log/qdrouterd.log
> >>> >> > }
> >>> >> >
> >>> >> > When you run your management request, you will see proton frame
> trace
> >>> >> > and
> >>> >> > you will see additional logging out of the dispatch Python agent -
> >>> >> > something like the following -
> >>> >> >
> >>> >> > Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
> >>> >> > Message(address=None,
> >>> >> > properties={'operation': 'CREATE', 'type':
> >>> >> > 'org.apache.qpid.dispatch.connector',
> >>> >> > 'name': 'rabih.connector'}, body={'port': '5673', 'role':
> >>> >> > 'route-container', 'addr': 'broker-machine', 'name':
> >>> 'rabih.connector'},
> >>> >> > reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
> >>> >> > correlation_id=1L)
> >>> >> > Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
> >>> >> > broker-machine:5673 proto=any, role=route-container
> >>> >> > Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
> >>> >> > ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
> >>> >> > host=127.0.0.1, identity=connector/127.0.0.1:
> 5673:rabih.connector,
> >>> >> > idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
> >>> >> > name=rabih.connector, port=5673, role=route-container,
> >>> >> > stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
> >>> >> > verifyHostName=True)
> >>> >> >
> >>> >> > The Python management agent will not process your request if
> there is
> >>> no
> >>> >> > reply_to as seen here -
> >>> >> >
> >>> >> > https://github.com/apache/qpid-dispatch/blob/master/
> >>> >> > python/qpid_dispatch_internal/management/agent.py#L822
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> Can I ask why the agent doesn't process the request? Just because
> there
> >>> >> is
> >>> >> a reply-to doesn't mean that the sender will be around to actually
> hear
> >>> >> the
> >>> >> reply, so it seems a bit arbitrary to say that because we *know* the
> >>> >> sender
> >>> >> won't learn of the outcome that we won't do anything... The spec
> draft
> >>> >> doesn't currently say anything about this (obviously it should do),
> but
> >>> my
> >>> >> expectation would certainly be that a request would be processed
> even if
> >>> >> the replyTo address was not present (or ended up not routing
> anywhere).
> >>> >> This is also how the Qpid Broker for Java implements this case.
> >>> >>
> >>> >> -- Rob
> >>> >>
> >>> >>
> >>> >> > Thanks.
> >>> >> >
> >>> >> > >
> >>> >> > > Robbie
> >>> >> > >
> >>> >> > > ------------------------------------------------------------
> >>> ---------
> >>> >> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>> >> > > For additional commands, e-mail: users-help@qpid.apache.org
> >>> >> > >
> >>> >> > >
> >>> >> >
> >>> >> > ------------------------------------------------------------
> ---------
> >>> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>> >> > For additional commands, e-mail: users-help@qpid.apache.org
> >>> >> >
> >>> >> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > ------------------------------------------------------------
> ---------
> >>> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>> > For additional commands, e-mail: users-help@qpid.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Adel Boutros <Ad...@live.com>.
Thanks Robbie for taking a look.
We can live with a real queue for now. However from the whole discussion, it seems what we are doing using JMS is not officially supported.
To what extent are you going to commit to this support?
Would it be dropped soon? Would it be officialised soon?
What we like about JMS is the procedural calls when compared to Proton's reactive API.
Regards,
Adel
________________________________
From: Robbie Gemmell <ro...@gmail.com>
Sent: Wednesday, February 1, 2017 5:07:02 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
I've had a look at this. It would seem that Dispatch doesn't like what
the client is doing for createTemporaryQueue, but doesn't fail in a
very nice way, and the client then doesnt notice that things have gone
south in a somewhat unexpected way.
The client opens a sending link with 'dynamic' target in order to
create a dynamic node for use as a TemporaryQueue address/destination
object, which specific consumers/producers are then created against by
the application. Dispatch doesn't seem to like that but erroneously
attaches the link 'successfully', though doesnt set a target address
as is expected. The client then doesnt notice this happened (its
checking for the link being refused, which it wasn't), allowing the
application to proceed as far as creating consumers/procuers using the
TemporaryQueue object, with creation of the e.g Consumer then failing
since the attach doesnt contain the needed information and leads to
Dispatch detaching it with the error (though it again doesnt actually
indicate its refusing the link during the attach response, as it
probably should have in this case).
Making the client detect the current failure and having it throw an
aexception from createTemporaryQueue is simple enough.
Hacking the client to use a dynamic recieving link instead, an address
was returned by Dispatch in the attach response as expected, however a
consumer on the resulting TemporaryQueue object using this address
still didnt get the message I sent to the same place. If I also gave
some credit on the link backing the TemporaryQeueue object itself then
that link gets sent the message by Dispatch, though this of no use for
the JMS client.
Needs some more investigation, and I'll need to discuss with some
folks more familiar with Dispatch.
Robbie
On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com> wrote:
> Hello Robbie,
>
>
> I replaced the "createQueue" with "createTemporaryQueue" for the reply consumer and activated PN_TRACE_FRM on Dispatch Router and JMS Client.
>
>
> PS: As Rabih stated before, we are using the same connection and same session to create the JMSProducer for the request and the JMSConsumer for the reply.
>
>
> Exception
> -------------------
> javax.jms.IllegalStateException: The MessageConsumer was closed due to an unrecoverable error.
> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessageConsumer.java:330)
> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageConsumer.java:196)
> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: javax.jms.JMSException: No route to the destination node [condition = qd:no-route-to-dest]
> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:150)
> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:105)
> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remotelyClosed(AmqpAbstractResource.java:147)
> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:251)
> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:795)
> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:90)
> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:699)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
>
> -------------------
> Dispatch Router (PN_TRACE_FRM=1)
> -------------------
>
> [832220]: <- SASL
> [832220]: -> SASL
> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b"", hostname="host-name"]
> [832220]:0 -> @sasl-outcome(68) [code=0]
> [832220]: <- AMQP
> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-a334-44c3-954a-2dd910161411:1", hostname="host-name", max-frame-size=1048576, channel-max=32767, idle-time-out=30000, desired-capabilities=@PN_SYMBOL[:"sole-connection-for-container"], properties={:product="QpidJMS", :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64"}]
> [832220]: -> AMQP
> [832220]:0 -> @open(16) [container-id="router.10200", max-frame-size=16384, channel-max=32767, idle-time-out=8000, offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router", :version="0.7.0"}]
> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047, outgoing-window=2147483647, handle-max=65535]
> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=61, outgoing-window=2147483647]
> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047, outgoing-window=2147483647, handle-max=65535]
> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0, incoming-window=61, outgoing-window=2147483647]
> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]], target=@target(41) [address="$management", durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false, initial-delivery-count=0]
> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0, timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]], target=@target(41) [address="$management", durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]], initial-delivery-count=0, max-message-size=0]
> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=250, drain=false]
> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-creator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [], target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=true, dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"temporary-queue"]], incomplete-unsettled=false, initial-delivery-count=0]
> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-creator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=true, dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"temporary-queue"]], initial-delivery-count=0, max-message-size=0]
> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=250, drain=false]
> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=true, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, default-outcome=@modified(39) [delivery-failed=true], outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list", :"amqp:released:list", :"amqp:modified:list"], capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41) []]
> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29) [condition=:"qd:no-route-to-dest", description="No route to the destination node"]]
> [832220]:1 <- @detach(22) [handle=1, closed=true]
> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"0", message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.dispatch.connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1, link-credit=250, drain=false]
> [832220]:1 -> @disposition(21) [role=true, first=0, last=0, settled=true, state=@accepted(36) []]
> [832220]:0 <- @close(24) []
> [832220]: <- EOS
> [832220]:0 -> @close(24) []
> [832220]: -> EOS
> Closed x.x.x.x:8961
> Unexpected poll events: 0020 on x.x.x.x:8961
> Unexpected poll events: 0020 on x.x.x.x:8961
>
> ------------------
> JMS Client (PN_TRACE_FRM=1)
> ------------------
> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-4a22-9b22-69d27a017a83:1', hostname='host-name', maxFrameSize=1048576, channelMax=32767, idleTimeOut=30000, outgoingLocales=null, incomingLocales=null, offeredCapabilities=null, desiredCapabilities=[sole-connection-for-container], properties={product=QpidJMS, version=0.11.1, platform=JVM: 1.8.0_111, 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
> [1244186219:0] <- Open{ containerId='router.10200', hostname='null', maxFrameSize=16384, channelMax=32767, idleTimeOut=8000, outgoingLocales=null, incomingLocales=null, offeredCapabilities=[ANONYMOUS-RELAY], desiredCapabilities=null, properties={product=qpid-dispatch-router, version=0.7.0}}
> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1, incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1, incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0, incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] -> Attach{name='qpid-jms:sender:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list], capabilities=null}, target=Target{address='$management', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] <- Attach{name='qpid-jms:sender:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list], capabilities=null}, target=Target{address='$management', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61, nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0, linkCredit=250, available=null, drain=false, echo=false, properties=null}
> [1244186219:0] -> Attach{name='qpid-jms:temp-queue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, target=Target{address='null', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0, dynamic=true, dynamicNodeProperties={lifetime-policy=DeleteOnClose{}}, capabilities=[temporary-queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:0] <- Attach{name='qpid-jms:temp-queue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, target=Target{address='null', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0, dynamic=true, dynamicNodeProperties={lifetime-policy=DeleteOnClose{}}, capabilities=[temporary-queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61, nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0, linkCredit=250, available=null, drain=false, echo=false, properties=null}
> [1244186219:1] -> Attach{name='qpid-jms:receiver:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=Modified{deliveryFailed=true, undeliverableHere=null, messageAnnotations=null}, outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, amqp:modified:list], capabilities=[temporary-queue]}, target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] <- Attach{name='qpid-jms:receiver:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] <- Detach{handle=1, closed=true, error=Error{condition=qd:no-route-to-dest, description='No route to the destination node', info=null}}
> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0, messageFormat=0, settled=null, more=false, rcvSettleMode=null, state=null, resume=false, aborted=false, batchable=false} (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.dispatch.connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61, nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=1, linkCredit=250, available=null, drain=false, echo=false, properties=null}
> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0, settled=true, state=Accepted{}, batchable=false}
> [1244186219:0] -> Close{error=null}
> [1244186219:0] <- Close{error=null}
>
> Regards,
>
> Adel
>
> ________________________________
> From: Robbie Gemmell <ro...@gmail.com>
> Sent: Tuesday, January 24, 2017 7:33:32 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> That looks fine at first glance. Its possible there is an issue in
> there needing looked it. I am travelling this week so may not get to
> look until afterwards, but will try to give things a look at. If you
> could give more detail on the exception and maybe a protocol trace
> that might be useful.
>
> Robbie
>
> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
>> Hello Robbie,
>>
>> Thanks for you for your answer.
>> I will try the solutions you proposed.
>>
>> I need just need one clarification. Concerning the Jms, I already tried to
>> use a temporary queue but it didn't work. May be i am using it wrong. Here
>> is what i did:
>>
>> ...
>> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
>> Queue queue = session.createQueue("$management");
>> MessageProducer producer = session.createProducer(queue);
>>
>> Queue tempDest = session.createTemporaryQueue();
>> MessageConsumer responseConsumer = session.createConsumer(tempDest);
>> connection.start();
>>
>> ObjectMessage objectMessage = session.createObjectMessage();
>> objectMessage.setJMSReplyTo(tempDest);
>> //fill the rest of the parameters ...
>> producer.send(objectMessage);
>> ObjectMessage replyMessage = (ObjectMessage) responseConsumer.receive(1000);
>> ...
>>
>> I was getting an exception on the .receive() from the dispatch router
>> saying that the reply-to address is bad...
>> Should i create the temporary queue and the consumer from a different
>> session then the producer?
>>
>> Best regards,
>> Rabih
>>
>>
>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <ro...@gmail.com>
>> wrote:
>>
>>> The session.createTemporaryQueue(); method is how JMS creates
>>> temporary destinations for use in reply-to scenarios. The dispatch
>>> tools will be doing essentially the same thing under the covers for
>>> theirs.
>>>
>>> Both work by creating a 'dynamic' link attachment, with the server
>>> returning an address for the dynamic attach to the client. One key
>>> difference is with JMS you create the temporary destination (for which
>>> the client uses a dynamic sender link to create), then separately
>>> create a receiver using it (and in turn the address associated with
>>> it), whereas non-JMS client/tools will typically just create a single
>>> dynamic receiver link and use its address for the reply-to.
>>>
>>> For proton-j, there aren't any examples for this, but you you
>>> essentially would change the link opening to not specify an address,
>>> and instead set the source(for a receiver) or target (for a sender) to
>>> be 'dynamic'. You would then inspect the remoteSource or remoteTarget
>>> once the link had been reemotely attached, and get its
>>> (server-generated) address, then use this as your reply-to.
>>>
>>> Robbie
>>>
>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com> wrote:
>>> > Hello,
>>> >
>>> > When I added to the JMS test the ".setJMSReplyTo()" queue, like you
>>> > suggested, it worked.
>>> > But I cheated a little to make it work because I did not find a way in
>>> JMS
>>> > to create a local queue. So I created a queue on the qpid-dispatch and
>>> read
>>> > the result from it. You can check the attached code.
>>> >
>>> > Is there any way using qpid-jms to create a local queue on the client
>>> side
>>> > to serve as a reply to address?
>>> >
>>> > For the proton-j test, I have the same question as above. I saw that it
>>> can
>>> > be done with the C++ API. Are there any examples for proton-j or
>>> something
>>> > that can help me?
>>> >
>>> > I saw may be in proton we don't need a local queue, may be we can get the
>>> > address of the consumer directly and pass it in reply-to field. Is it
>>> > correct?
>>> >
>>> > Thanks,
>>> > Rabih
>>> >
>>> >
>>> >
>>> > On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <ro...@gmail.com>
>>> > wrote:
>>> >>
>>> >> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com> wrote:
>>> >>
>>> >> >
>>> >> >
>>> >> > ----- Original Message -----
>>> >> > > From: "Robbie Gemmell" <ro...@gmail.com>
>>> >> > > To: users@qpid.apache.org
>>> >> > > Sent: Friday, January 20, 2017 2:18:45 PM
>>> >> > > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>> >> > >
>>> >> > > On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
>>> >> > > > On 20/01/17 18:40, Rabih M wrote:
>>> >> > > >>
>>> >> > > >> I inserted the map directly into the ObjectMessage like you told
>>> me
>>> >> > > >> Robbie and it worked.
>>> >> > > >>
>>> >> > > >> But like the proton-j case, the connector is not being created on
>>> >> > > >> the
>>> >> > > >> Qpid-dispatch side.
>>> >> > > >> I attached the amqp communication into this mail.
>>> >> > > >
>>> >> > > >
>>> >> > > > The last frame in that file is incomplete (the previous error
>>> >> > regarding the
>>> >> > > > map body may or may not be a wireshark issue),but that last frame
>>> is
>>> >> > likely
>>> >> > > > the response which would indicate the success or otherwise of the
>>> >> > frame. Is
>>> >> > > > there anything logged by the router?
>>> >> > > >
>>> >> > > > If you can, just running the router with PN_TRACE_FRM=1 is simpler
>>> >> > > > for
>>> >> > this
>>> >> > > > sort of thing in my view.
>>> >> > > >
>>> >> > >
>>> >> > > As Gordon suggests, the proton trace logs might be more helpful. You
>>> >> > > can also do that with proton-j, and this the JMS client too since it
>>> >> > > uses proton-j.
>>> >> > >
>>> >> > > One key difference from the qdmanage case is you are not setting a
>>> >> > > reply-to value or correlation-id to use along with it. I don't know
>>> if
>>> >> > > the router cares about not being able to send a response or not
>>> >> > > though, but it might.
>>> >> >
>>> >> > You could add the following to your dispatch router conf file
>>> >> > (qdrouterd.conf) and restart the router (This will enable trace
>>> logging)
>>> >> >
>>> >> > log {
>>> >> > module: DEFAULT
>>> >> > enable: trace+
>>> >> > output: /path/to/log/qdrouterd.log
>>> >> > }
>>> >> >
>>> >> > When you run your management request, you will see proton frame trace
>>> >> > and
>>> >> > you will see additional logging out of the dispatch Python agent -
>>> >> > something like the following -
>>> >> >
>>> >> > Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>>> >> > Message(address=None,
>>> >> > properties={'operation': 'CREATE', 'type':
>>> >> > 'org.apache.qpid.dispatch.connector',
>>> >> > 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>>> >> > 'route-container', 'addr': 'broker-machine', 'name':
>>> 'rabih.connector'},
>>> >> > reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>>> >> > correlation_id=1L)
>>> >> > Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>>> >> > broker-machine:5673 proto=any, role=route-container
>>> >> > Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>>> >> > ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
>>> >> > host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector,
>>> >> > idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>>> >> > name=rabih.connector, port=5673, role=route-container,
>>> >> > stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
>>> >> > verifyHostName=True)
>>> >> >
>>> >> > The Python management agent will not process your request if there is
>>> no
>>> >> > reply_to as seen here -
>>> >> >
>>> >> > https://github.com/apache/qpid-dispatch/blob/master/
>>> >> > python/qpid_dispatch_internal/management/agent.py#L822
>>> >> >
>>> >> >
>>> >> >
>>> >> Can I ask why the agent doesn't process the request? Just because there
>>> >> is
>>> >> a reply-to doesn't mean that the sender will be around to actually hear
>>> >> the
>>> >> reply, so it seems a bit arbitrary to say that because we *know* the
>>> >> sender
>>> >> won't learn of the outcome that we won't do anything... The spec draft
>>> >> doesn't currently say anything about this (obviously it should do), but
>>> my
>>> >> expectation would certainly be that a request would be processed even if
>>> >> the replyTo address was not present (or ended up not routing anywhere).
>>> >> This is also how the Qpid Broker for Java implements this case.
>>> >>
>>> >> -- Rob
>>> >>
>>> >>
>>> >> > Thanks.
>>> >> >
>>> >> > >
>>> >> > > Robbie
>>> >> > >
>>> >> > > ------------------------------------------------------------
>>> ---------
>>> >> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> > > For additional commands, e-mail: users-help@qpid.apache.org
>>> >> > >
>>> >> > >
>>> >> >
>>> >> > ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> > For additional commands, e-mail: users-help@qpid.apache.org
>>> >> >
>>> >> >
>>> >
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> > For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Robbie Gemmell <ro...@gmail.com>.
I've had a look at this. It would seem that Dispatch doesn't like what
the client is doing for createTemporaryQueue, but doesn't fail in a
very nice way, and the client then doesnt notice that things have gone
south in a somewhat unexpected way.
The client opens a sending link with 'dynamic' target in order to
create a dynamic node for use as a TemporaryQueue address/destination
object, which specific consumers/producers are then created against by
the application. Dispatch doesn't seem to like that but erroneously
attaches the link 'successfully', though doesnt set a target address
as is expected. The client then doesnt notice this happened (its
checking for the link being refused, which it wasn't), allowing the
application to proceed as far as creating consumers/procuers using the
TemporaryQueue object, with creation of the e.g Consumer then failing
since the attach doesnt contain the needed information and leads to
Dispatch detaching it with the error (though it again doesnt actually
indicate its refusing the link during the attach response, as it
probably should have in this case).
Making the client detect the current failure and having it throw an
aexception from createTemporaryQueue is simple enough.
Hacking the client to use a dynamic recieving link instead, an address
was returned by Dispatch in the attach response as expected, however a
consumer on the resulting TemporaryQueue object using this address
still didnt get the message I sent to the same place. If I also gave
some credit on the link backing the TemporaryQeueue object itself then
that link gets sent the message by Dispatch, though this of no use for
the JMS client.
Needs some more investigation, and I'll need to discuss with some
folks more familiar with Dispatch.
Robbie
On 26 January 2017 at 13:39, Adel Boutros <Ad...@live.com> wrote:
> Hello Robbie,
>
>
> I replaced the "createQueue" with "createTemporaryQueue" for the reply consumer and activated PN_TRACE_FRM on Dispatch Router and JMS Client.
>
>
> PS: As Rabih stated before, we are using the same connection and same session to create the JMSProducer for the request and the JMSConsumer for the reply.
>
>
> Exception
> -------------------
> javax.jms.IllegalStateException: The MessageConsumer was closed due to an unrecoverable error.
> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessageConsumer.java:330)
> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageConsumer.java:196)
> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: javax.jms.JMSException: No route to the destination node [condition = qd:no-route-to-dest]
> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:150)
> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:105)
> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remotelyClosed(AmqpAbstractResource.java:147)
> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:251)
> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:795)
> at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:90)
> at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:699)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
>
> -------------------
> Dispatch Router (PN_TRACE_FRM=1)
> -------------------
>
> [832220]: <- SASL
> [832220]: -> SASL
> [832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b"", hostname="host-name"]
> [832220]:0 -> @sasl-outcome(68) [code=0]
> [832220]: <- AMQP
> [832220]:0 <- @open(16) [container-id="ID:9d96ddb8-a334-44c3-954a-2dd910161411:1", hostname="host-name", max-frame-size=1048576, channel-max=32767, idle-time-out=30000, desired-capabilities=@PN_SYMBOL[:"sole-connection-for-container"], properties={:product="QpidJMS", :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64"}]
> [832220]: -> AMQP
> [832220]:0 -> @open(16) [container-id="router.10200", max-frame-size=16384, channel-max=32767, idle-time-out=8000, offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router", :version="0.7.0"}]
> [832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047, outgoing-window=2147483647, handle-max=65535]
> [832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=61, outgoing-window=2147483647]
> [832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047, outgoing-window=2147483647, handle-max=65535]
> [832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0, incoming-window=61, outgoing-window=2147483647]
> [832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]], target=@target(41) [address="$management", durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false, initial-delivery-count=0]
> [832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0, timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]], target=@target(41) [address="$management", durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]], initial-delivery-count=0, max-message-size=0]
> [832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=250, drain=false]
> [832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-creator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [], target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=true, dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"temporary-queue"]], incomplete-unsettled=false, initial-delivery-count=0]
> [832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-creator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=true, dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"temporary-queue"]], initial-delivery-count=0, max-message-size=0]
> [832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=250, drain=false]
> [832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=true, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, default-outcome=@modified(39) [delivery-failed=true], outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list", :"amqp:released:list", :"amqp:modified:list"], capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41) []]
> [832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
> [832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29) [condition=:"qd:no-route-to-dest", description="No route to the destination node"]]
> [832220]:1 <- @detach(22) [handle=1, closed=true]
> [832220]:1 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"0", message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.dispatch.connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
> [832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1, link-credit=250, drain=false]
> [832220]:1 -> @disposition(21) [role=true, first=0, last=0, settled=true, state=@accepted(36) []]
> [832220]:0 <- @close(24) []
> [832220]: <- EOS
> [832220]:0 -> @close(24) []
> [832220]: -> EOS
> Closed x.x.x.x:8961
> Unexpected poll events: 0020 on x.x.x.x:8961
> Unexpected poll events: 0020 on x.x.x.x:8961
>
> ------------------
> JMS Client (PN_TRACE_FRM=1)
> ------------------
> [1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-4a22-9b22-69d27a017a83:1', hostname='host-name', maxFrameSize=1048576, channelMax=32767, idleTimeOut=30000, outgoingLocales=null, incomingLocales=null, offeredCapabilities=null, desiredCapabilities=[sole-connection-for-container], properties={product=QpidJMS, version=0.11.1, platform=JVM: 1.8.0_111, 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
> [1244186219:0] <- Open{ containerId='router.10200', hostname='null', maxFrameSize=16384, channelMax=32767, idleTimeOut=8000, outgoingLocales=null, incomingLocales=null, offeredCapabilities=[ANONYMOUS-RELAY], desiredCapabilities=null, properties={product=qpid-dispatch-router, version=0.7.0}}
> [1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1, incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1, incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0, incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] -> Attach{name='qpid-jms:sender:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list], capabilities=null}, target=Target{address='$management', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] <- Attach{name='qpid-jms:sender:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list], capabilities=null}, target=Target{address='$management', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61, nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0, linkCredit=250, available=null, drain=false, echo=false, properties=null}
> [1244186219:0] -> Attach{name='qpid-jms:temp-queue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, target=Target{address='null', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0, dynamic=true, dynamicNodeProperties={lifetime-policy=DeleteOnClose{}}, capabilities=[temporary-queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:0] <- Attach{name='qpid-jms:temp-queue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, target=Target{address='null', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0, dynamic=true, dynamicNodeProperties={lifetime-policy=DeleteOnClose{}}, capabilities=[temporary-queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61, nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0, linkCredit=250, available=null, drain=false, echo=false, properties=null}
> [1244186219:1] -> Attach{name='qpid-jms:receiver:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=Modified{deliveryFailed=true, undeliverableHere=null, messageAnnotations=null}, outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, amqp:modified:list], capabilities=[temporary-queue]}, target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] <- Attach{name='qpid-jms:receiver:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1244186219:1] <- Detach{handle=1, closed=true, error=Error{condition=qd:no-route-to-dest, description='No route to the destination node', info=null}}
> [1244186219:1] -> Detach{handle=1, closed=true, error=null}
> [1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0, messageFormat=0, settled=null, more=false, rcvSettleMode=null, state=null, resume=false, aborted=false, batchable=false} (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.dispatch.connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
> [1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61, nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=1, linkCredit=250, available=null, drain=false, echo=false, properties=null}
> [1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0, settled=true, state=Accepted{}, batchable=false}
> [1244186219:0] -> Close{error=null}
> [1244186219:0] <- Close{error=null}
>
> Regards,
>
> Adel
>
> ________________________________
> From: Robbie Gemmell <ro...@gmail.com>
> Sent: Tuesday, January 24, 2017 7:33:32 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> That looks fine at first glance. Its possible there is an issue in
> there needing looked it. I am travelling this week so may not get to
> look until afterwards, but will try to give things a look at. If you
> could give more detail on the exception and maybe a protocol trace
> that might be useful.
>
> Robbie
>
> On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
>> Hello Robbie,
>>
>> Thanks for you for your answer.
>> I will try the solutions you proposed.
>>
>> I need just need one clarification. Concerning the Jms, I already tried to
>> use a temporary queue but it didn't work. May be i am using it wrong. Here
>> is what i did:
>>
>> ...
>> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
>> Queue queue = session.createQueue("$management");
>> MessageProducer producer = session.createProducer(queue);
>>
>> Queue tempDest = session.createTemporaryQueue();
>> MessageConsumer responseConsumer = session.createConsumer(tempDest);
>> connection.start();
>>
>> ObjectMessage objectMessage = session.createObjectMessage();
>> objectMessage.setJMSReplyTo(tempDest);
>> //fill the rest of the parameters ...
>> producer.send(objectMessage);
>> ObjectMessage replyMessage = (ObjectMessage) responseConsumer.receive(1000);
>> ...
>>
>> I was getting an exception on the .receive() from the dispatch router
>> saying that the reply-to address is bad...
>> Should i create the temporary queue and the consumer from a different
>> session then the producer?
>>
>> Best regards,
>> Rabih
>>
>>
>> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <ro...@gmail.com>
>> wrote:
>>
>>> The session.createTemporaryQueue(); method is how JMS creates
>>> temporary destinations for use in reply-to scenarios. The dispatch
>>> tools will be doing essentially the same thing under the covers for
>>> theirs.
>>>
>>> Both work by creating a 'dynamic' link attachment, with the server
>>> returning an address for the dynamic attach to the client. One key
>>> difference is with JMS you create the temporary destination (for which
>>> the client uses a dynamic sender link to create), then separately
>>> create a receiver using it (and in turn the address associated with
>>> it), whereas non-JMS client/tools will typically just create a single
>>> dynamic receiver link and use its address for the reply-to.
>>>
>>> For proton-j, there aren't any examples for this, but you you
>>> essentially would change the link opening to not specify an address,
>>> and instead set the source(for a receiver) or target (for a sender) to
>>> be 'dynamic'. You would then inspect the remoteSource or remoteTarget
>>> once the link had been reemotely attached, and get its
>>> (server-generated) address, then use this as your reply-to.
>>>
>>> Robbie
>>>
>>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com> wrote:
>>> > Hello,
>>> >
>>> > When I added to the JMS test the ".setJMSReplyTo()" queue, like you
>>> > suggested, it worked.
>>> > But I cheated a little to make it work because I did not find a way in
>>> JMS
>>> > to create a local queue. So I created a queue on the qpid-dispatch and
>>> read
>>> > the result from it. You can check the attached code.
>>> >
>>> > Is there any way using qpid-jms to create a local queue on the client
>>> side
>>> > to serve as a reply to address?
>>> >
>>> > For the proton-j test, I have the same question as above. I saw that it
>>> can
>>> > be done with the C++ API. Are there any examples for proton-j or
>>> something
>>> > that can help me?
>>> >
>>> > I saw may be in proton we don't need a local queue, may be we can get the
>>> > address of the consumer directly and pass it in reply-to field. Is it
>>> > correct?
>>> >
>>> > Thanks,
>>> > Rabih
>>> >
>>> >
>>> >
>>> > On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <ro...@gmail.com>
>>> > wrote:
>>> >>
>>> >> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com> wrote:
>>> >>
>>> >> >
>>> >> >
>>> >> > ----- Original Message -----
>>> >> > > From: "Robbie Gemmell" <ro...@gmail.com>
>>> >> > > To: users@qpid.apache.org
>>> >> > > Sent: Friday, January 20, 2017 2:18:45 PM
>>> >> > > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>> >> > >
>>> >> > > On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
>>> >> > > > On 20/01/17 18:40, Rabih M wrote:
>>> >> > > >>
>>> >> > > >> I inserted the map directly into the ObjectMessage like you told
>>> me
>>> >> > > >> Robbie and it worked.
>>> >> > > >>
>>> >> > > >> But like the proton-j case, the connector is not being created on
>>> >> > > >> the
>>> >> > > >> Qpid-dispatch side.
>>> >> > > >> I attached the amqp communication into this mail.
>>> >> > > >
>>> >> > > >
>>> >> > > > The last frame in that file is incomplete (the previous error
>>> >> > regarding the
>>> >> > > > map body may or may not be a wireshark issue),but that last frame
>>> is
>>> >> > likely
>>> >> > > > the response which would indicate the success or otherwise of the
>>> >> > frame. Is
>>> >> > > > there anything logged by the router?
>>> >> > > >
>>> >> > > > If you can, just running the router with PN_TRACE_FRM=1 is simpler
>>> >> > > > for
>>> >> > this
>>> >> > > > sort of thing in my view.
>>> >> > > >
>>> >> > >
>>> >> > > As Gordon suggests, the proton trace logs might be more helpful. You
>>> >> > > can also do that with proton-j, and this the JMS client too since it
>>> >> > > uses proton-j.
>>> >> > >
>>> >> > > One key difference from the qdmanage case is you are not setting a
>>> >> > > reply-to value or correlation-id to use along with it. I don't know
>>> if
>>> >> > > the router cares about not being able to send a response or not
>>> >> > > though, but it might.
>>> >> >
>>> >> > You could add the following to your dispatch router conf file
>>> >> > (qdrouterd.conf) and restart the router (This will enable trace
>>> logging)
>>> >> >
>>> >> > log {
>>> >> > module: DEFAULT
>>> >> > enable: trace+
>>> >> > output: /path/to/log/qdrouterd.log
>>> >> > }
>>> >> >
>>> >> > When you run your management request, you will see proton frame trace
>>> >> > and
>>> >> > you will see additional logging out of the dispatch Python agent -
>>> >> > something like the following -
>>> >> >
>>> >> > Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>>> >> > Message(address=None,
>>> >> > properties={'operation': 'CREATE', 'type':
>>> >> > 'org.apache.qpid.dispatch.connector',
>>> >> > 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>>> >> > 'route-container', 'addr': 'broker-machine', 'name':
>>> 'rabih.connector'},
>>> >> > reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>>> >> > correlation_id=1L)
>>> >> > Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>>> >> > broker-machine:5673 proto=any, role=route-container
>>> >> > Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>>> >> > ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
>>> >> > host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector,
>>> >> > idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>>> >> > name=rabih.connector, port=5673, role=route-container,
>>> >> > stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
>>> >> > verifyHostName=True)
>>> >> >
>>> >> > The Python management agent will not process your request if there is
>>> no
>>> >> > reply_to as seen here -
>>> >> >
>>> >> > https://github.com/apache/qpid-dispatch/blob/master/
>>> >> > python/qpid_dispatch_internal/management/agent.py#L822
>>> >> >
>>> >> >
>>> >> >
>>> >> Can I ask why the agent doesn't process the request? Just because there
>>> >> is
>>> >> a reply-to doesn't mean that the sender will be around to actually hear
>>> >> the
>>> >> reply, so it seems a bit arbitrary to say that because we *know* the
>>> >> sender
>>> >> won't learn of the outcome that we won't do anything... The spec draft
>>> >> doesn't currently say anything about this (obviously it should do), but
>>> my
>>> >> expectation would certainly be that a request would be processed even if
>>> >> the replyTo address was not present (or ended up not routing anywhere).
>>> >> This is also how the Qpid Broker for Java implements this case.
>>> >>
>>> >> -- Rob
>>> >>
>>> >>
>>> >> > Thanks.
>>> >> >
>>> >> > >
>>> >> > > Robbie
>>> >> > >
>>> >> > > ------------------------------------------------------------
>>> ---------
>>> >> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> > > For additional commands, e-mail: users-help@qpid.apache.org
>>> >> > >
>>> >> > >
>>> >> >
>>> >> > ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> > For additional commands, e-mail: users-help@qpid.apache.org
>>> >> >
>>> >> >
>>> >
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> > For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Adel Boutros <Ad...@live.com>.
Hello Robbie,
I replaced the "createQueue" with "createTemporaryQueue" for the reply consumer and activated PN_TRACE_FRM on Dispatch Router and JMS Client.
PS: As Rabih stated before, we are using the same connection and same session to create the JMSProducer for the request and the JMSConsumer for the reply.
Exception
-------------------
javax.jms.IllegalStateException: The MessageConsumer was closed due to an unrecoverable error.
at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessageConsumer.java:330)
at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageConsumer.java:196)
at murex.messaging.client.JmsTest.main(JmsTest.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: javax.jms.JMSException: No route to the destination node [condition = qd:no-route-to-dest]
at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:150)
at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:105)
at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remotelyClosed(AmqpAbstractResource.java:147)
at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:251)
at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:795)
at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:90)
at org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:699)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
-------------------
Dispatch Router (PN_TRACE_FRM=1)
-------------------
[832220]: <- SASL
[832220]: -> SASL
[832220]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
[832220]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b"", hostname="host-name"]
[832220]:0 -> @sasl-outcome(68) [code=0]
[832220]: <- AMQP
[832220]:0 <- @open(16) [container-id="ID:9d96ddb8-a334-44c3-954a-2dd910161411:1", hostname="host-name", max-frame-size=1048576, channel-max=32767, idle-time-out=30000, desired-capabilities=@PN_SYMBOL[:"sole-connection-for-container"], properties={:product="QpidJMS", :version="0.11.1", :platform="JVM: 1.8.0_111, 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64"}]
[832220]: -> AMQP
[832220]:0 -> @open(16) [container-id="router.10200", max-frame-size=16384, channel-max=32767, idle-time-out=8000, offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router", :version="0.7.0"}]
[832220]:0 <- @begin(17) [next-outgoing-id=1, incoming-window=2047, outgoing-window=2147483647, handle-max=65535]
[832220]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=61, outgoing-window=2147483647]
[832220]:1 <- @begin(17) [next-outgoing-id=1, incoming-window=2047, outgoing-window=2147483647, handle-max=65535]
[832220]:1 -> @begin(17) [remote-channel=1, next-outgoing-id=0, incoming-window=61, outgoing-window=2147483647]
[832220]:1 <- @attach(18) [name="qpid-jms:sender:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]], target=@target(41) [address="$management", durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false, initial-delivery-count=0]
[832220]:1 -> @attach(18) [name="qpid-jms:sender:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:$management", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1", durable=0, timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list"]], target=@target(41) [address="$management", durable=0, timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]], initial-delivery-count=0, max-message-size=0]
[832220]:1 -> @flow(19) [next-incoming-id=1, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=250, drain=false]
[832220]:0 <- @attach(18) [name="qpid-jms:temp-queue-creator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [], target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=true, dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"temporary-queue"]], incomplete-unsettled=false, initial-delivery-count=0]
[832220]:0 -> @attach(18) [name="qpid-jms:temp-queue-creator:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=true, dynamic-node-properties={:"lifetime-policy"=@delete-on-close(43) []}, capabilities=@PN_SYMBOL[:"temporary-queue"]], initial-delivery-count=0, max-message-size=0]
[832220]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=250, drain=false]
[832220]:1 <- @attach(18) [name="qpid-jms:receiver:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=true, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, default-outcome=@modified(39) [delivery-failed=true], outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list", :"amqp:released:list", :"amqp:modified:list"], capabilities=@PN_SYMBOL[:"temporary-queue"]], target=@target(41) []]
[832220]:1 -> @attach(18) [name="qpid-jms:receiver:ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1:null", handle=1, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
[832220]:1 -> @detach(22) [handle=1, closed=true, error=@error(29) [condition=:"qd:no-route-to-dest", description="No route to the destination node"]]
[832220]:1 <- @detach(22) [handle=1, closed=true]
[832220]:1 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"0", message-format=0] (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:8ec755cd-dc3f-47cc-9f39-f5d15647fe80:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\x01Y\xda\xf2\xa6'\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.dispatch.connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
[832220]:1 -> @flow(19) [next-incoming-id=2, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1, link-credit=250, drain=false]
[832220]:1 -> @disposition(21) [role=true, first=0, last=0, settled=true, state=@accepted(36) []]
[832220]:0 <- @close(24) []
[832220]: <- EOS
[832220]:0 -> @close(24) []
[832220]: -> EOS
Closed x.x.x.x:8961
Unexpected poll events: 0020 on x.x.x.x:8961
Unexpected poll events: 0020 on x.x.x.x:8961
------------------
JMS Client (PN_TRACE_FRM=1)
------------------
[1244186219:0] -> Open{ containerId='ID:da8ce84a-c69b-4a22-9b22-69d27a017a83:1', hostname='host-name', maxFrameSize=1048576, channelMax=32767, idleTimeOut=30000, outgoingLocales=null, incomingLocales=null, offeredCapabilities=null, desiredCapabilities=[sole-connection-for-container], properties={product=QpidJMS, version=0.11.1, platform=JVM: 1.8.0_111, 25.111-b14, Oracle Corporation, OS: Windows 7, 6.1, amd64}}
[1244186219:0] <- Open{ containerId='router.10200', hostname='null', maxFrameSize=16384, channelMax=32767, idleTimeOut=8000, outgoingLocales=null, incomingLocales=null, offeredCapabilities=[ANONYMOUS-RELAY], desiredCapabilities=null, properties={product=qpid-dispatch-router, version=0.7.0}}
[1244186219:0] -> Begin{remoteChannel=null, nextOutgoingId=1, incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535, offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1244186219:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295, offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1244186219:1] -> Begin{remoteChannel=null, nextOutgoingId=1, incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535, offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1244186219:1] <- Begin{remoteChannel=1, nextOutgoingId=0, incomingWindow=61, outgoingWindow=2147483647, handleMax=4294967295, offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1244186219:1] -> Attach{name='qpid-jms:sender:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list], capabilities=null}, target=Target{address='$management', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1244186219:1] <- Attach{name='qpid-jms:sender:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:$management', handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list], capabilities=null}, target=Target{address='$management', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1244186219:1] <- Flow{nextIncomingId=1, incomingWindow=61, nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0, linkCredit=250, available=null, drain=false, echo=false, properties=null}
[1244186219:0] -> Attach{name='qpid-jms:temp-queue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, target=Target{address='null', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0, dynamic=true, dynamicNodeProperties={lifetime-policy=DeleteOnClose{}}, capabilities=[temporary-queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1244186219:0] <- Attach{name='qpid-jms:temp-queue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, target=Target{address='null', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0, dynamic=true, dynamicNodeProperties={lifetime-policy=DeleteOnClose{}}, capabilities=[temporary-queue]}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61, nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0, linkCredit=250, available=null, drain=false, echo=false, properties=null}
[1244186219:1] -> Attach{name='qpid-jms:receiver:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=Modified{deliveryFailed=true, undeliverableHere=null, messageAnnotations=null}, outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, amqp:modified:list], capabilities=[temporary-queue]}, target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1244186219:1] <- Attach{name='qpid-jms:receiver:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1:null', handle=1, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1244186219:1] <- Detach{handle=1, closed=true, error=Error{condition=qd:no-route-to-dest, description='No route to the destination node', info=null}}
[1244186219:1] -> Detach{handle=1, closed=true, error=null}
[1244186219:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0, messageFormat=0, settled=null, more=false, rcvSettleMode=null, state=null, resume=false, aborted=false, batchable=false} (312) "\x00Sp\xc0\x02\x01A\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@@@@@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.dispatch.connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-container\xa1\x04port\xa1\x04port\xa1\x04name\xa1\x0frabih.connector\xa1\x04addr\xa1\x0dbrokerMachine"
[1244186219:1] <- Flow{nextIncomingId=2, incomingWindow=61, nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=1, linkCredit=250, available=null, drain=false, echo=false, properties=null}
[1244186219:1] <- Disposition{role=RECEIVER, first=0, last=0, settled=true, state=Accepted{}, batchable=false}
[1244186219:0] -> Close{error=null}
[1244186219:0] <- Close{error=null}
Regards,
Adel
________________________________
From: Robbie Gemmell <ro...@gmail.com>
Sent: Tuesday, January 24, 2017 7:33:32 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
That looks fine at first glance. Its possible there is an issue in
there needing looked it. I am travelling this week so may not get to
look until afterwards, but will try to give things a look at. If you
could give more detail on the exception and maybe a protocol trace
that might be useful.
Robbie
On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
> Hello Robbie,
>
> Thanks for you for your answer.
> I will try the solutions you proposed.
>
> I need just need one clarification. Concerning the Jms, I already tried to
> use a temporary queue but it didn't work. May be i am using it wrong. Here
> is what i did:
>
> ...
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> Queue queue = session.createQueue("$management");
> MessageProducer producer = session.createProducer(queue);
>
> Queue tempDest = session.createTemporaryQueue();
> MessageConsumer responseConsumer = session.createConsumer(tempDest);
> connection.start();
>
> ObjectMessage objectMessage = session.createObjectMessage();
> objectMessage.setJMSReplyTo(tempDest);
> //fill the rest of the parameters ...
> producer.send(objectMessage);
> ObjectMessage replyMessage = (ObjectMessage) responseConsumer.receive(1000);
> ...
>
> I was getting an exception on the .receive() from the dispatch router
> saying that the reply-to address is bad...
> Should i create the temporary queue and the consumer from a different
> session then the producer?
>
> Best regards,
> Rabih
>
>
> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> The session.createTemporaryQueue(); method is how JMS creates
>> temporary destinations for use in reply-to scenarios. The dispatch
>> tools will be doing essentially the same thing under the covers for
>> theirs.
>>
>> Both work by creating a 'dynamic' link attachment, with the server
>> returning an address for the dynamic attach to the client. One key
>> difference is with JMS you create the temporary destination (for which
>> the client uses a dynamic sender link to create), then separately
>> create a receiver using it (and in turn the address associated with
>> it), whereas non-JMS client/tools will typically just create a single
>> dynamic receiver link and use its address for the reply-to.
>>
>> For proton-j, there aren't any examples for this, but you you
>> essentially would change the link opening to not specify an address,
>> and instead set the source(for a receiver) or target (for a sender) to
>> be 'dynamic'. You would then inspect the remoteSource or remoteTarget
>> once the link had been reemotely attached, and get its
>> (server-generated) address, then use this as your reply-to.
>>
>> Robbie
>>
>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com> wrote:
>> > Hello,
>> >
>> > When I added to the JMS test the ".setJMSReplyTo()" queue, like you
>> > suggested, it worked.
>> > But I cheated a little to make it work because I did not find a way in
>> JMS
>> > to create a local queue. So I created a queue on the qpid-dispatch and
>> read
>> > the result from it. You can check the attached code.
>> >
>> > Is there any way using qpid-jms to create a local queue on the client
>> side
>> > to serve as a reply to address?
>> >
>> > For the proton-j test, I have the same question as above. I saw that it
>> can
>> > be done with the C++ API. Are there any examples for proton-j or
>> something
>> > that can help me?
>> >
>> > I saw may be in proton we don't need a local queue, may be we can get the
>> > address of the consumer directly and pass it in reply-to field. Is it
>> > correct?
>> >
>> > Thanks,
>> > Rabih
>> >
>> >
>> >
>> > On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <ro...@gmail.com>
>> > wrote:
>> >>
>> >> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com> wrote:
>> >>
>> >> >
>> >> >
>> >> > ----- Original Message -----
>> >> > > From: "Robbie Gemmell" <ro...@gmail.com>
>> >> > > To: users@qpid.apache.org
>> >> > > Sent: Friday, January 20, 2017 2:18:45 PM
>> >> > > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>> >> > >
>> >> > > On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
>> >> > > > On 20/01/17 18:40, Rabih M wrote:
>> >> > > >>
>> >> > > >> I inserted the map directly into the ObjectMessage like you told
>> me
>> >> > > >> Robbie and it worked.
>> >> > > >>
>> >> > > >> But like the proton-j case, the connector is not being created on
>> >> > > >> the
>> >> > > >> Qpid-dispatch side.
>> >> > > >> I attached the amqp communication into this mail.
>> >> > > >
>> >> > > >
>> >> > > > The last frame in that file is incomplete (the previous error
>> >> > regarding the
>> >> > > > map body may or may not be a wireshark issue),but that last frame
>> is
>> >> > likely
>> >> > > > the response which would indicate the success or otherwise of the
>> >> > frame. Is
>> >> > > > there anything logged by the router?
>> >> > > >
>> >> > > > If you can, just running the router with PN_TRACE_FRM=1 is simpler
>> >> > > > for
>> >> > this
>> >> > > > sort of thing in my view.
>> >> > > >
>> >> > >
>> >> > > As Gordon suggests, the proton trace logs might be more helpful. You
>> >> > > can also do that with proton-j, and this the JMS client too since it
>> >> > > uses proton-j.
>> >> > >
>> >> > > One key difference from the qdmanage case is you are not setting a
>> >> > > reply-to value or correlation-id to use along with it. I don't know
>> if
>> >> > > the router cares about not being able to send a response or not
>> >> > > though, but it might.
>> >> >
>> >> > You could add the following to your dispatch router conf file
>> >> > (qdrouterd.conf) and restart the router (This will enable trace
>> logging)
>> >> >
>> >> > log {
>> >> > module: DEFAULT
>> >> > enable: trace+
>> >> > output: /path/to/log/qdrouterd.log
>> >> > }
>> >> >
>> >> > When you run your management request, you will see proton frame trace
>> >> > and
>> >> > you will see additional logging out of the dispatch Python agent -
>> >> > something like the following -
>> >> >
>> >> > Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>> >> > Message(address=None,
>> >> > properties={'operation': 'CREATE', 'type':
>> >> > 'org.apache.qpid.dispatch.connector',
>> >> > 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>> >> > 'route-container', 'addr': 'broker-machine', 'name':
>> 'rabih.connector'},
>> >> > reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>> >> > correlation_id=1L)
>> >> > Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>> >> > broker-machine:5673 proto=any, role=route-container
>> >> > Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>> >> > ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
>> >> > host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector,
>> >> > idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>> >> > name=rabih.connector, port=5673, role=route-container,
>> >> > stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
>> >> > verifyHostName=True)
>> >> >
>> >> > The Python management agent will not process your request if there is
>> no
>> >> > reply_to as seen here -
>> >> >
>> >> > https://github.com/apache/qpid-dispatch/blob/master/
>> >> > python/qpid_dispatch_internal/management/agent.py#L822
>> >> >
>> >> >
>> >> >
>> >> Can I ask why the agent doesn't process the request? Just because there
>> >> is
>> >> a reply-to doesn't mean that the sender will be around to actually hear
>> >> the
>> >> reply, so it seems a bit arbitrary to say that because we *know* the
>> >> sender
>> >> won't learn of the outcome that we won't do anything... The spec draft
>> >> doesn't currently say anything about this (obviously it should do), but
>> my
>> >> expectation would certainly be that a request would be processed even if
>> >> the replyTo address was not present (or ended up not routing anywhere).
>> >> This is also how the Qpid Broker for Java implements this case.
>> >>
>> >> -- Rob
>> >>
>> >>
>> >> > Thanks.
>> >> >
>> >> > >
>> >> > > Robbie
>> >> > >
>> >> > > ------------------------------------------------------------
>> ---------
>> >> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> > > For additional commands, e-mail: users-help@qpid.apache.org
>> >> > >
>> >> > >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> > For additional commands, e-mail: users-help@qpid.apache.org
>> >> >
>> >> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: users-help@qpid.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Robbie Gemmell <ro...@gmail.com>.
That looks fine at first glance. Its possible there is an issue in
there needing looked it. I am travelling this week so may not get to
look until afterwards, but will try to give things a look at. If you
could give more detail on the exception and maybe a protocol trace
that might be useful.
Robbie
On 24 January 2017 at 13:14, Rabih M <ra...@gmail.com> wrote:
> Hello Robbie,
>
> Thanks for you for your answer.
> I will try the solutions you proposed.
>
> I need just need one clarification. Concerning the Jms, I already tried to
> use a temporary queue but it didn't work. May be i am using it wrong. Here
> is what i did:
>
> ...
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> Queue queue = session.createQueue("$management");
> MessageProducer producer = session.createProducer(queue);
>
> Queue tempDest = session.createTemporaryQueue();
> MessageConsumer responseConsumer = session.createConsumer(tempDest);
> connection.start();
>
> ObjectMessage objectMessage = session.createObjectMessage();
> objectMessage.setJMSReplyTo(tempDest);
> //fill the rest of the parameters ...
> producer.send(objectMessage);
> ObjectMessage replyMessage = (ObjectMessage) responseConsumer.receive(1000);
> ...
>
> I was getting an exception on the .receive() from the dispatch router
> saying that the reply-to address is bad...
> Should i create the temporary queue and the consumer from a different
> session then the producer?
>
> Best regards,
> Rabih
>
>
> On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> The session.createTemporaryQueue(); method is how JMS creates
>> temporary destinations for use in reply-to scenarios. The dispatch
>> tools will be doing essentially the same thing under the covers for
>> theirs.
>>
>> Both work by creating a 'dynamic' link attachment, with the server
>> returning an address for the dynamic attach to the client. One key
>> difference is with JMS you create the temporary destination (for which
>> the client uses a dynamic sender link to create), then separately
>> create a receiver using it (and in turn the address associated with
>> it), whereas non-JMS client/tools will typically just create a single
>> dynamic receiver link and use its address for the reply-to.
>>
>> For proton-j, there aren't any examples for this, but you you
>> essentially would change the link opening to not specify an address,
>> and instead set the source(for a receiver) or target (for a sender) to
>> be 'dynamic'. You would then inspect the remoteSource or remoteTarget
>> once the link had been reemotely attached, and get its
>> (server-generated) address, then use this as your reply-to.
>>
>> Robbie
>>
>> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com> wrote:
>> > Hello,
>> >
>> > When I added to the JMS test the ".setJMSReplyTo()" queue, like you
>> > suggested, it worked.
>> > But I cheated a little to make it work because I did not find a way in
>> JMS
>> > to create a local queue. So I created a queue on the qpid-dispatch and
>> read
>> > the result from it. You can check the attached code.
>> >
>> > Is there any way using qpid-jms to create a local queue on the client
>> side
>> > to serve as a reply to address?
>> >
>> > For the proton-j test, I have the same question as above. I saw that it
>> can
>> > be done with the C++ API. Are there any examples for proton-j or
>> something
>> > that can help me?
>> >
>> > I saw may be in proton we don't need a local queue, may be we can get the
>> > address of the consumer directly and pass it in reply-to field. Is it
>> > correct?
>> >
>> > Thanks,
>> > Rabih
>> >
>> >
>> >
>> > On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <ro...@gmail.com>
>> > wrote:
>> >>
>> >> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com> wrote:
>> >>
>> >> >
>> >> >
>> >> > ----- Original Message -----
>> >> > > From: "Robbie Gemmell" <ro...@gmail.com>
>> >> > > To: users@qpid.apache.org
>> >> > > Sent: Friday, January 20, 2017 2:18:45 PM
>> >> > > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>> >> > >
>> >> > > On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
>> >> > > > On 20/01/17 18:40, Rabih M wrote:
>> >> > > >>
>> >> > > >> I inserted the map directly into the ObjectMessage like you told
>> me
>> >> > > >> Robbie and it worked.
>> >> > > >>
>> >> > > >> But like the proton-j case, the connector is not being created on
>> >> > > >> the
>> >> > > >> Qpid-dispatch side.
>> >> > > >> I attached the amqp communication into this mail.
>> >> > > >
>> >> > > >
>> >> > > > The last frame in that file is incomplete (the previous error
>> >> > regarding the
>> >> > > > map body may or may not be a wireshark issue),but that last frame
>> is
>> >> > likely
>> >> > > > the response which would indicate the success or otherwise of the
>> >> > frame. Is
>> >> > > > there anything logged by the router?
>> >> > > >
>> >> > > > If you can, just running the router with PN_TRACE_FRM=1 is simpler
>> >> > > > for
>> >> > this
>> >> > > > sort of thing in my view.
>> >> > > >
>> >> > >
>> >> > > As Gordon suggests, the proton trace logs might be more helpful. You
>> >> > > can also do that with proton-j, and this the JMS client too since it
>> >> > > uses proton-j.
>> >> > >
>> >> > > One key difference from the qdmanage case is you are not setting a
>> >> > > reply-to value or correlation-id to use along with it. I don't know
>> if
>> >> > > the router cares about not being able to send a response or not
>> >> > > though, but it might.
>> >> >
>> >> > You could add the following to your dispatch router conf file
>> >> > (qdrouterd.conf) and restart the router (This will enable trace
>> logging)
>> >> >
>> >> > log {
>> >> > module: DEFAULT
>> >> > enable: trace+
>> >> > output: /path/to/log/qdrouterd.log
>> >> > }
>> >> >
>> >> > When you run your management request, you will see proton frame trace
>> >> > and
>> >> > you will see additional logging out of the dispatch Python agent -
>> >> > something like the following -
>> >> >
>> >> > Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>> >> > Message(address=None,
>> >> > properties={'operation': 'CREATE', 'type':
>> >> > 'org.apache.qpid.dispatch.connector',
>> >> > 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>> >> > 'route-container', 'addr': 'broker-machine', 'name':
>> 'rabih.connector'},
>> >> > reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>> >> > correlation_id=1L)
>> >> > Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>> >> > broker-machine:5673 proto=any, role=route-container
>> >> > Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>> >> > ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
>> >> > host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector,
>> >> > idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>> >> > name=rabih.connector, port=5673, role=route-container,
>> >> > stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
>> >> > verifyHostName=True)
>> >> >
>> >> > The Python management agent will not process your request if there is
>> no
>> >> > reply_to as seen here -
>> >> >
>> >> > https://github.com/apache/qpid-dispatch/blob/master/
>> >> > python/qpid_dispatch_internal/management/agent.py#L822
>> >> >
>> >> >
>> >> >
>> >> Can I ask why the agent doesn't process the request? Just because there
>> >> is
>> >> a reply-to doesn't mean that the sender will be around to actually hear
>> >> the
>> >> reply, so it seems a bit arbitrary to say that because we *know* the
>> >> sender
>> >> won't learn of the outcome that we won't do anything... The spec draft
>> >> doesn't currently say anything about this (obviously it should do), but
>> my
>> >> expectation would certainly be that a request would be processed even if
>> >> the replyTo address was not present (or ended up not routing anywhere).
>> >> This is also how the Qpid Broker for Java implements this case.
>> >>
>> >> -- Rob
>> >>
>> >>
>> >> > Thanks.
>> >> >
>> >> > >
>> >> > > Robbie
>> >> > >
>> >> > > ------------------------------------------------------------
>> ---------
>> >> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> > > For additional commands, e-mail: users-help@qpid.apache.org
>> >> > >
>> >> > >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> > For additional commands, e-mail: users-help@qpid.apache.org
>> >> >
>> >> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: users-help@qpid.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Rabih M <ra...@gmail.com>.
Hello Robbie,
Thanks for you for your answer.
I will try the solutions you proposed.
I need just need one clarification. Concerning the Jms, I already tried to
use a temporary queue but it didn't work. May be i am using it wrong. Here
is what i did:
...
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
Queue queue = session.createQueue("$management");
MessageProducer producer = session.createProducer(queue);
Queue tempDest = session.createTemporaryQueue();
MessageConsumer responseConsumer = session.createConsumer(tempDest);
connection.start();
ObjectMessage objectMessage = session.createObjectMessage();
objectMessage.setJMSReplyTo(tempDest);
//fill the rest of the parameters ...
producer.send(objectMessage);
ObjectMessage replyMessage = (ObjectMessage) responseConsumer.receive(1000);
...
I was getting an exception on the .receive() from the dispatch router
saying that the reply-to address is bad...
Should i create the temporary queue and the consumer from a different
session then the producer?
Best regards,
Rabih
On Tue, Jan 24, 2017 at 5:37 PM, Robbie Gemmell <ro...@gmail.com>
wrote:
> The session.createTemporaryQueue(); method is how JMS creates
> temporary destinations for use in reply-to scenarios. The dispatch
> tools will be doing essentially the same thing under the covers for
> theirs.
>
> Both work by creating a 'dynamic' link attachment, with the server
> returning an address for the dynamic attach to the client. One key
> difference is with JMS you create the temporary destination (for which
> the client uses a dynamic sender link to create), then separately
> create a receiver using it (and in turn the address associated with
> it), whereas non-JMS client/tools will typically just create a single
> dynamic receiver link and use its address for the reply-to.
>
> For proton-j, there aren't any examples for this, but you you
> essentially would change the link opening to not specify an address,
> and instead set the source(for a receiver) or target (for a sender) to
> be 'dynamic'. You would then inspect the remoteSource or remoteTarget
> once the link had been reemotely attached, and get its
> (server-generated) address, then use this as your reply-to.
>
> Robbie
>
> On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com> wrote:
> > Hello,
> >
> > When I added to the JMS test the ".setJMSReplyTo()" queue, like you
> > suggested, it worked.
> > But I cheated a little to make it work because I did not find a way in
> JMS
> > to create a local queue. So I created a queue on the qpid-dispatch and
> read
> > the result from it. You can check the attached code.
> >
> > Is there any way using qpid-jms to create a local queue on the client
> side
> > to serve as a reply to address?
> >
> > For the proton-j test, I have the same question as above. I saw that it
> can
> > be done with the C++ API. Are there any examples for proton-j or
> something
> > that can help me?
> >
> > I saw may be in proton we don't need a local queue, may be we can get the
> > address of the consumer directly and pass it in reply-to field. Is it
> > correct?
> >
> > Thanks,
> > Rabih
> >
> >
> >
> > On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <ro...@gmail.com>
> > wrote:
> >>
> >> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com> wrote:
> >>
> >> >
> >> >
> >> > ----- Original Message -----
> >> > > From: "Robbie Gemmell" <ro...@gmail.com>
> >> > > To: users@qpid.apache.org
> >> > > Sent: Friday, January 20, 2017 2:18:45 PM
> >> > > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >> > >
> >> > > On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
> >> > > > On 20/01/17 18:40, Rabih M wrote:
> >> > > >>
> >> > > >> I inserted the map directly into the ObjectMessage like you told
> me
> >> > > >> Robbie and it worked.
> >> > > >>
> >> > > >> But like the proton-j case, the connector is not being created on
> >> > > >> the
> >> > > >> Qpid-dispatch side.
> >> > > >> I attached the amqp communication into this mail.
> >> > > >
> >> > > >
> >> > > > The last frame in that file is incomplete (the previous error
> >> > regarding the
> >> > > > map body may or may not be a wireshark issue),but that last frame
> is
> >> > likely
> >> > > > the response which would indicate the success or otherwise of the
> >> > frame. Is
> >> > > > there anything logged by the router?
> >> > > >
> >> > > > If you can, just running the router with PN_TRACE_FRM=1 is simpler
> >> > > > for
> >> > this
> >> > > > sort of thing in my view.
> >> > > >
> >> > >
> >> > > As Gordon suggests, the proton trace logs might be more helpful. You
> >> > > can also do that with proton-j, and this the JMS client too since it
> >> > > uses proton-j.
> >> > >
> >> > > One key difference from the qdmanage case is you are not setting a
> >> > > reply-to value or correlation-id to use along with it. I don't know
> if
> >> > > the router cares about not being able to send a response or not
> >> > > though, but it might.
> >> >
> >> > You could add the following to your dispatch router conf file
> >> > (qdrouterd.conf) and restart the router (This will enable trace
> logging)
> >> >
> >> > log {
> >> > module: DEFAULT
> >> > enable: trace+
> >> > output: /path/to/log/qdrouterd.log
> >> > }
> >> >
> >> > When you run your management request, you will see proton frame trace
> >> > and
> >> > you will see additional logging out of the dispatch Python agent -
> >> > something like the following -
> >> >
> >> > Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
> >> > Message(address=None,
> >> > properties={'operation': 'CREATE', 'type':
> >> > 'org.apache.qpid.dispatch.connector',
> >> > 'name': 'rabih.connector'}, body={'port': '5673', 'role':
> >> > 'route-container', 'addr': 'broker-machine', 'name':
> 'rabih.connector'},
> >> > reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
> >> > correlation_id=1L)
> >> > Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
> >> > broker-machine:5673 proto=any, role=route-container
> >> > Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
> >> > ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
> >> > host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector,
> >> > idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
> >> > name=rabih.connector, port=5673, role=route-container,
> >> > stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
> >> > verifyHostName=True)
> >> >
> >> > The Python management agent will not process your request if there is
> no
> >> > reply_to as seen here -
> >> >
> >> > https://github.com/apache/qpid-dispatch/blob/master/
> >> > python/qpid_dispatch_internal/management/agent.py#L822
> >> >
> >> >
> >> >
> >> Can I ask why the agent doesn't process the request? Just because there
> >> is
> >> a reply-to doesn't mean that the sender will be around to actually hear
> >> the
> >> reply, so it seems a bit arbitrary to say that because we *know* the
> >> sender
> >> won't learn of the outcome that we won't do anything... The spec draft
> >> doesn't currently say anything about this (obviously it should do), but
> my
> >> expectation would certainly be that a request would be processed even if
> >> the replyTo address was not present (or ended up not routing anywhere).
> >> This is also how the Qpid Broker for Java implements this case.
> >>
> >> -- Rob
> >>
> >>
> >> > Thanks.
> >> >
> >> > >
> >> > > Robbie
> >> > >
> >> > > ------------------------------------------------------------
> ---------
> >> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> > > For additional commands, e-mail: users-help@qpid.apache.org
> >> > >
> >> > >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> > For additional commands, e-mail: users-help@qpid.apache.org
> >> >
> >> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Robbie Gemmell <ro...@gmail.com>.
The session.createTemporaryQueue(); method is how JMS creates
temporary destinations for use in reply-to scenarios. The dispatch
tools will be doing essentially the same thing under the covers for
theirs.
Both work by creating a 'dynamic' link attachment, with the server
returning an address for the dynamic attach to the client. One key
difference is with JMS you create the temporary destination (for which
the client uses a dynamic sender link to create), then separately
create a receiver using it (and in turn the address associated with
it), whereas non-JMS client/tools will typically just create a single
dynamic receiver link and use its address for the reply-to.
For proton-j, there aren't any examples for this, but you you
essentially would change the link opening to not specify an address,
and instead set the source(for a receiver) or target (for a sender) to
be 'dynamic'. You would then inspect the remoteSource or remoteTarget
once the link had been reemotely attached, and get its
(server-generated) address, then use this as your reply-to.
Robbie
On 23 January 2017 at 11:00, Rabih M <ra...@gmail.com> wrote:
> Hello,
>
> When I added to the JMS test the ".setJMSReplyTo()" queue, like you
> suggested, it worked.
> But I cheated a little to make it work because I did not find a way in JMS
> to create a local queue. So I created a queue on the qpid-dispatch and read
> the result from it. You can check the attached code.
>
> Is there any way using qpid-jms to create a local queue on the client side
> to serve as a reply to address?
>
> For the proton-j test, I have the same question as above. I saw that it can
> be done with the C++ API. Are there any examples for proton-j or something
> that can help me?
>
> I saw may be in proton we don't need a local queue, may be we can get the
> address of the consumer directly and pass it in reply-to field. Is it
> correct?
>
> Thanks,
> Rabih
>
>
>
> On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <ro...@gmail.com>
> wrote:
>>
>> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com> wrote:
>>
>> >
>> >
>> > ----- Original Message -----
>> > > From: "Robbie Gemmell" <ro...@gmail.com>
>> > > To: users@qpid.apache.org
>> > > Sent: Friday, January 20, 2017 2:18:45 PM
>> > > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>> > >
>> > > On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
>> > > > On 20/01/17 18:40, Rabih M wrote:
>> > > >>
>> > > >> I inserted the map directly into the ObjectMessage like you told me
>> > > >> Robbie and it worked.
>> > > >>
>> > > >> But like the proton-j case, the connector is not being created on
>> > > >> the
>> > > >> Qpid-dispatch side.
>> > > >> I attached the amqp communication into this mail.
>> > > >
>> > > >
>> > > > The last frame in that file is incomplete (the previous error
>> > regarding the
>> > > > map body may or may not be a wireshark issue),but that last frame is
>> > likely
>> > > > the response which would indicate the success or otherwise of the
>> > frame. Is
>> > > > there anything logged by the router?
>> > > >
>> > > > If you can, just running the router with PN_TRACE_FRM=1 is simpler
>> > > > for
>> > this
>> > > > sort of thing in my view.
>> > > >
>> > >
>> > > As Gordon suggests, the proton trace logs might be more helpful. You
>> > > can also do that with proton-j, and this the JMS client too since it
>> > > uses proton-j.
>> > >
>> > > One key difference from the qdmanage case is you are not setting a
>> > > reply-to value or correlation-id to use along with it. I don't know if
>> > > the router cares about not being able to send a response or not
>> > > though, but it might.
>> >
>> > You could add the following to your dispatch router conf file
>> > (qdrouterd.conf) and restart the router (This will enable trace logging)
>> >
>> > log {
>> > module: DEFAULT
>> > enable: trace+
>> > output: /path/to/log/qdrouterd.log
>> > }
>> >
>> > When you run your management request, you will see proton frame trace
>> > and
>> > you will see additional logging out of the dispatch Python agent -
>> > something like the following -
>> >
>> > Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
>> > Message(address=None,
>> > properties={'operation': 'CREATE', 'type':
>> > 'org.apache.qpid.dispatch.connector',
>> > 'name': 'rabih.connector'}, body={'port': '5673', 'role':
>> > 'route-container', 'addr': 'broker-machine', 'name': 'rabih.connector'},
>> > reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
>> > correlation_id=1L)
>> > Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
>> > broker-machine:5673 proto=any, role=route-container
>> > Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
>> > ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
>> > host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector,
>> > idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
>> > name=rabih.connector, port=5673, role=route-container,
>> > stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
>> > verifyHostName=True)
>> >
>> > The Python management agent will not process your request if there is no
>> > reply_to as seen here -
>> >
>> > https://github.com/apache/qpid-dispatch/blob/master/
>> > python/qpid_dispatch_internal/management/agent.py#L822
>> >
>> >
>> >
>> Can I ask why the agent doesn't process the request? Just because there
>> is
>> a reply-to doesn't mean that the sender will be around to actually hear
>> the
>> reply, so it seems a bit arbitrary to say that because we *know* the
>> sender
>> won't learn of the outcome that we won't do anything... The spec draft
>> doesn't currently say anything about this (obviously it should do), but my
>> expectation would certainly be that a request would be processed even if
>> the replyTo address was not present (or ended up not routing anywhere).
>> This is also how the Qpid Broker for Java implements this case.
>>
>> -- Rob
>>
>>
>> > Thanks.
>> >
>> > >
>> > > Robbie
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> > > For additional commands, e-mail: users-help@qpid.apache.org
>> > >
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: users-help@qpid.apache.org
>> >
>> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Rabih M <ra...@gmail.com>.
Hello,
When I added to the JMS test the ".setJMSReplyTo()" queue, like you
suggested, it worked.
But I cheated a little to make it work because I did not find a way in JMS
to create a local queue. So I created a queue on the qpid-dispatch and read
the result from it. You can check the attached code.
Is there any way using qpid-jms to create a local queue on the client side
to serve as a reply to address?
For the proton-j test, I have the same question as above. I saw that it can
be done with the C++ API. Are there any examples for proton-j or something
that can help me?
I saw may be in proton we don't need a local queue, may be we can get the
address of the consumer directly and pass it in reply-to field. Is it
correct?
Thanks,
Rabih
On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey <ro...@gmail.com>
wrote:
> On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com> wrote:
>
> >
> >
> > ----- Original Message -----
> > > From: "Robbie Gemmell" <ro...@gmail.com>
> > > To: users@qpid.apache.org
> > > Sent: Friday, January 20, 2017 2:18:45 PM
> > > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> > >
> > > On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
> > > > On 20/01/17 18:40, Rabih M wrote:
> > > >>
> > > >> I inserted the map directly into the ObjectMessage like you told me
> > > >> Robbie and it worked.
> > > >>
> > > >> But like the proton-j case, the connector is not being created on
> the
> > > >> Qpid-dispatch side.
> > > >> I attached the amqp communication into this mail.
> > > >
> > > >
> > > > The last frame in that file is incomplete (the previous error
> > regarding the
> > > > map body may or may not be a wireshark issue),but that last frame is
> > likely
> > > > the response which would indicate the success or otherwise of the
> > frame. Is
> > > > there anything logged by the router?
> > > >
> > > > If you can, just running the router with PN_TRACE_FRM=1 is simpler
> for
> > this
> > > > sort of thing in my view.
> > > >
> > >
> > > As Gordon suggests, the proton trace logs might be more helpful. You
> > > can also do that with proton-j, and this the JMS client too since it
> > > uses proton-j.
> > >
> > > One key difference from the qdmanage case is you are not setting a
> > > reply-to value or correlation-id to use along with it. I don't know if
> > > the router cares about not being able to send a response or not
> > > though, but it might.
> >
> > You could add the following to your dispatch router conf file
> > (qdrouterd.conf) and restart the router (This will enable trace logging)
> >
> > log {
> > module: DEFAULT
> > enable: trace+
> > output: /path/to/log/qdrouterd.log
> > }
> >
> > When you run your management request, you will see proton frame trace and
> > you will see additional logging out of the dispatch Python agent -
> > something like the following -
> >
> > Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request
> Message(address=None,
> > properties={'operation': 'CREATE', 'type': 'org.apache.qpid.dispatch.
> connector',
> > 'name': 'rabih.connector'}, body={'port': '5673', 'role':
> > 'route-container', 'addr': 'broker-machine', 'name': 'rabih.connector'},
> > reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx',
> correlation_id=1L)
> > Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
> > broker-machine:5673 proto=any, role=route-container
> > Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
> > ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
> > host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector,
> > idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
> > name=rabih.connector, port=5673, role=route-container,
> > stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
> > verifyHostName=True)
> >
> > The Python management agent will not process your request if there is no
> > reply_to as seen here -
> >
> > https://github.com/apache/qpid-dispatch/blob/master/
> > python/qpid_dispatch_internal/management/agent.py#L822
> >
> >
> >
> Can I ask why the agent doesn't process the request? Just because there is
> a reply-to doesn't mean that the sender will be around to actually hear the
> reply, so it seems a bit arbitrary to say that because we *know* the sender
> won't learn of the outcome that we won't do anything... The spec draft
> doesn't currently say anything about this (obviously it should do), but my
> expectation would certainly be that a request would be processed even if
> the replyTo address was not present (or ended up not routing anywhere).
> This is also how the Qpid Broker for Java implements this case.
>
> -- Rob
>
>
> > Thanks.
> >
> > >
> > > Robbie
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Rob Godfrey <ro...@gmail.com>.
On 20 January 2017 at 21:45, Ganesh Murthy <gm...@redhat.com> wrote:
>
>
> ----- Original Message -----
> > From: "Robbie Gemmell" <ro...@gmail.com>
> > To: users@qpid.apache.org
> > Sent: Friday, January 20, 2017 2:18:45 PM
> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >
> > On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
> > > On 20/01/17 18:40, Rabih M wrote:
> > >>
> > >> I inserted the map directly into the ObjectMessage like you told me
> > >> Robbie and it worked.
> > >>
> > >> But like the proton-j case, the connector is not being created on the
> > >> Qpid-dispatch side.
> > >> I attached the amqp communication into this mail.
> > >
> > >
> > > The last frame in that file is incomplete (the previous error
> regarding the
> > > map body may or may not be a wireshark issue),but that last frame is
> likely
> > > the response which would indicate the success or otherwise of the
> frame. Is
> > > there anything logged by the router?
> > >
> > > If you can, just running the router with PN_TRACE_FRM=1 is simpler for
> this
> > > sort of thing in my view.
> > >
> >
> > As Gordon suggests, the proton trace logs might be more helpful. You
> > can also do that with proton-j, and this the JMS client too since it
> > uses proton-j.
> >
> > One key difference from the qdmanage case is you are not setting a
> > reply-to value or correlation-id to use along with it. I don't know if
> > the router cares about not being able to send a response or not
> > though, but it might.
>
> You could add the following to your dispatch router conf file
> (qdrouterd.conf) and restart the router (This will enable trace logging)
>
> log {
> module: DEFAULT
> enable: trace+
> output: /path/to/log/qdrouterd.log
> }
>
> When you run your management request, you will see proton frame trace and
> you will see additional logging out of the dispatch Python agent -
> something like the following -
>
> Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request Message(address=None,
> properties={'operation': 'CREATE', 'type': 'org.apache.qpid.dispatch.connector',
> 'name': 'rabih.connector'}, body={'port': '5673', 'role':
> 'route-container', 'addr': 'broker-machine', 'name': 'rabih.connector'},
> reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx', correlation_id=1L)
> Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector:
> broker-machine:5673 proto=any, role=route-container
> Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity:
> ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1,
> host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector,
> idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768,
> name=rabih.connector, port=5673, role=route-container,
> stripAnnotations=both, type=org.apache.qpid.dispatch.connector,
> verifyHostName=True)
>
> The Python management agent will not process your request if there is no
> reply_to as seen here -
>
> https://github.com/apache/qpid-dispatch/blob/master/
> python/qpid_dispatch_internal/management/agent.py#L822
>
>
>
Can I ask why the agent doesn't process the request? Just because there is
a reply-to doesn't mean that the sender will be around to actually hear the
reply, so it seems a bit arbitrary to say that because we *know* the sender
won't learn of the outcome that we won't do anything... The spec draft
doesn't currently say anything about this (obviously it should do), but my
expectation would certainly be that a request would be processed even if
the replyTo address was not present (or ended up not routing anywhere).
This is also how the Qpid Broker for Java implements this case.
-- Rob
> Thanks.
>
> >
> > Robbie
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Ganesh Murthy <gm...@redhat.com>.
----- Original Message -----
> From: "Robbie Gemmell" <ro...@gmail.com>
> To: users@qpid.apache.org
> Sent: Friday, January 20, 2017 2:18:45 PM
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
> > On 20/01/17 18:40, Rabih M wrote:
> >>
> >> I inserted the map directly into the ObjectMessage like you told me
> >> Robbie and it worked.
> >>
> >> But like the proton-j case, the connector is not being created on the
> >> Qpid-dispatch side.
> >> I attached the amqp communication into this mail.
> >
> >
> > The last frame in that file is incomplete (the previous error regarding the
> > map body may or may not be a wireshark issue),but that last frame is likely
> > the response which would indicate the success or otherwise of the frame. Is
> > there anything logged by the router?
> >
> > If you can, just running the router with PN_TRACE_FRM=1 is simpler for this
> > sort of thing in my view.
> >
>
> As Gordon suggests, the proton trace logs might be more helpful. You
> can also do that with proton-j, and this the JMS client too since it
> uses proton-j.
>
> One key difference from the qdmanage case is you are not setting a
> reply-to value or correlation-id to use along with it. I don't know if
> the router cares about not being able to send a response or not
> though, but it might.
You could add the following to your dispatch router conf file (qdrouterd.conf) and restart the router (This will enable trace logging)
log {
module: DEFAULT
enable: trace+
output: /path/to/log/qdrouterd.log
}
When you run your management request, you will see proton frame trace and you will see additional logging out of the dispatch Python agent - something like the following -
Fri Jan 20 15:27:23 2017 AGENT (debug) Agent request Message(address=None, properties={'operation': 'CREATE', 'type': 'org.apache.qpid.dispatch.connector', 'name': 'rabih.connector'}, body={'port': '5673', 'role': 'route-container', 'addr': 'broker-machine', 'name': 'rabih.connector'}, reply_to='amqp:/_topo/0/Router.A/temp.i4H_ZOvee1xhGxx', correlation_id=1L)
Fri Jan 20 15:27:23 2017 CONN_MGR (info) Configured Connector: broker-machine:5673 proto=any, role=route-container
Fri Jan 20 15:27:23 2017 AGENT (debug) Add entity: ConnectorEntity(addr=broker-machine, allowRedirect=True, cost=1, host=127.0.0.1, identity=connector/127.0.0.1:5673:rabih.connector, idleTimeoutSeconds=16, maxFrameSize=16384, maxSessions=32768, name=rabih.connector, port=5673, role=route-container, stripAnnotations=both, type=org.apache.qpid.dispatch.connector, verifyHostName=True)
The Python management agent will not process your request if there is no reply_to as seen here -
https://github.com/apache/qpid-dispatch/blob/master/python/qpid_dispatch_internal/management/agent.py#L822
Thanks.
>
> Robbie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Robbie Gemmell <ro...@gmail.com>.
On 20 January 2017 at 19:06, Gordon Sim <gs...@redhat.com> wrote:
> On 20/01/17 18:40, Rabih M wrote:
>>
>> I inserted the map directly into the ObjectMessage like you told me
>> Robbie and it worked.
>>
>> But like the proton-j case, the connector is not being created on the
>> Qpid-dispatch side.
>> I attached the amqp communication into this mail.
>
>
> The last frame in that file is incomplete (the previous error regarding the
> map body may or may not be a wireshark issue),but that last frame is likely
> the response which would indicate the success or otherwise of the frame. Is
> there anything logged by the router?
>
> If you can, just running the router with PN_TRACE_FRM=1 is simpler for this
> sort of thing in my view.
>
As Gordon suggests, the proton trace logs might be more helpful. You
can also do that with proton-j, and this the JMS client too since it
uses proton-j.
One key difference from the qdmanage case is you are not setting a
reply-to value or correlation-id to use along with it. I don't know if
the router cares about not being able to send a response or not
though, but it might.
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Gordon Sim <gs...@redhat.com>.
On 20/01/17 18:40, Rabih M wrote:
> I inserted the map directly into the ObjectMessage like you told me
> Robbie and it worked.
>
> But like the proton-j case, the connector is not being created on the
> Qpid-dispatch side.
> I attached the amqp communication into this mail.
The last frame in that file is incomplete (the previous error regarding
the map body may or may not be a wireshark issue),but that last frame is
likely the response which would indicate the success or otherwise of the
frame. Is there anything logged by the router?
If you can, just running the router with PN_TRACE_FRM=1 is simpler for
this sort of thing in my view.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Rabih M <ra...@gmail.com>.
I inserted the map directly into the ObjectMessage like you told me Robbie
and it worked.
But like the proton-j case, the connector is not being created on the
Qpid-dispatch side.
I attached the amqp communication into this mail.
Best regards,
Rabih
On Fri, Jan 20, 2017 at 7:24 PM, Rabih M <ra...@gmail.com> wrote:
> Thanks Robbie,
>
> For the JMS, i will try to do that and i will keep you posted for the
> result.
>
> Concerning Proton-j:
> I configured the Target.
> But the connector is still not created on the qpid-dispatch side...
>
> I compared the sent packets using wireshark but i don't think there are
> significant differences.
> I attached the amqp exchanges in both cases.
>
> Do you think i have some missing info in my proton-j message?
>
> Thanks,
> Rabih
>
> On Fri, Jan 20, 2017 at 7:09 PM, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> On 20 January 2017 at 17:29, Rabih M <ra...@gmail.com> wrote:
>> > Hello,
>> >
>> > Thank you for you answers.
>> >
>> > I am trying to experiment to see if i can do it with the info you gave
>> me.
>> >
>> > I took a simple example to start: qdmanage -b <dispatch-machine>:5672
>> create
>> > --type=connector role=route-container addr=broker-machine port=5673
>> > name=rabih.connector
>> > My goal is to imitate the behavior using JMS and Proton-j.
>> >
>> > First, I tried with JMS (attached the code):
>> > I used an ObjectMessage with JMS_AMQP_TYPED_ENCODING set to true. And I
>> used
>> > the proton-j encoder to encode the map before sending it.
>> > But, I am getting a MessageFormatException("Failed to serialize object")
>> >
>> > Do you have any idea how can i pass the byte array without failing?
>> >
>>
>> I'd be rather surprised if this is actually what you want to do. I'd
>> expect you to set the map directly on the JMS ObjectMessage, and then
>> thanks to the special flag the client will encode it itself as an
>> amqp-value section containing a map (which now that ive kept reading,
>> matches what you are attempting with proton-j).
>>
>> >
>> > Second, I tried with Proton-j (attached code):
>> > The code i wrote is based on send example in proton-j.
>> > But the problem is that i am not able to find how to set the destination
>> > queue of the message. (i used Message.setAddress() but it is wrong)
>> >
>> > How can i set a destination queue for the sender or message?
>>
>> To give the link an addres you need to set the link 'source' and
>> 'target' and use the latter to indicate the address for the sending
>> link before you open it. E.g for address "queue", the most basic
>> config would be:
>>
>> + Target target = new Target();
>> + target.setAddress("queue");
>> + snd.setTarget(target );
>> + snd.setSource(new Source());
>>
>>
>> >
>> > PS. I used wireshark to see the amqp messages that are passing on the
>> > network and copy the message parameters.
>> >
>> >
>> > Best Regards,
>> > Rabih
>> >
>> > On Wed, Jan 18, 2017 at 2:35 PM, Rob Godfrey <ro...@gmail.com>
>> > wrote:
>> >>
>> >> So I think what we said - and I can't find it written down anywhere in
>> the
>> >> draft, though we reference the JSON spec in the pre-amble, is that any
>> >> value in the headers or body should be able to be sent in the native
>> AMQP
>> >> type (and we might need some words there about converting between
>> various
>> >> numeric types), or as a JSON serialized string. We didn't (to my
>> >> recollection) talk about whether there should be a way for the
>> requester
>> >> to
>> >> be able to influence the form of the reply.
>> >>
>> >> Currently the implementation of AMQP Management in the Qpid Broker for
>> >> Java
>> >> follows the above conventions (any inbound value can be in the native
>> >> type,
>> >> or as a JSON string which can convert to the desired type, however
>> there
>> >> is
>> >> no mechanism for controlling the nature of responses).
>> >>
>> >> Perhaps this is something we should talk about soon ;-) ?
>> >>
>> >> -- Rob
>> >>
>> >> On 18 January 2017 at 14:29, Ted Ross <tr...@redhat.com> wrote:
>> >>
>> >> >
>> >> >
>> >> > On 01/18/2017 07:45 AM, Gordon Sim wrote:
>> >> >
>> >> >> On 18/01/17 10:45, Rob Godfrey wrote:
>> >> >>
>> >> >>> In terms of sending maps/lists I think we said (at OASIS), though
>> it
>> >> >>> is
>> >> >>> possibly not yet in the draft spec, that Json formatted equivalents
>> >> >>> should
>> >> >>> be able to be used for all values... however I have no idea if the
>> >> >>> Dispatch
>> >> >>> Router supports that.
>> >> >>>
>> >> >>
>> >> >> I think that would be very sensible.
>> >> >>
>> >> >
>> >> > Dispatch Router does not support Json formatted bodies at present,
>> but
>> >> > this is a feature that I would be in favor of putting on the roadmap.
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >> ------------------------------------------------------------
>> ---------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >> For additional commands, e-mail: users-help@qpid.apache.org
>> >> >>
>> >> >>
>> >> > ------------------------------------------------------------
>> ---------
>> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> > For additional commands, e-mail: users-help@qpid.apache.org
>> >> >
>> >> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: users-help@qpid.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Rabih M <ra...@gmail.com>.
Thanks Robbie,
For the JMS, i will try to do that and i will keep you posted for the
result.
Concerning Proton-j:
I configured the Target.
But the connector is still not created on the qpid-dispatch side...
I compared the sent packets using wireshark but i don't think there are
significant differences.
I attached the amqp exchanges in both cases.
Do you think i have some missing info in my proton-j message?
Thanks,
Rabih
On Fri, Jan 20, 2017 at 7:09 PM, Robbie Gemmell <ro...@gmail.com>
wrote:
> On 20 January 2017 at 17:29, Rabih M <ra...@gmail.com> wrote:
> > Hello,
> >
> > Thank you for you answers.
> >
> > I am trying to experiment to see if i can do it with the info you gave
> me.
> >
> > I took a simple example to start: qdmanage -b <dispatch-machine>:5672
> create
> > --type=connector role=route-container addr=broker-machine port=5673
> > name=rabih.connector
> > My goal is to imitate the behavior using JMS and Proton-j.
> >
> > First, I tried with JMS (attached the code):
> > I used an ObjectMessage with JMS_AMQP_TYPED_ENCODING set to true. And I
> used
> > the proton-j encoder to encode the map before sending it.
> > But, I am getting a MessageFormatException("Failed to serialize object")
> >
> > Do you have any idea how can i pass the byte array without failing?
> >
>
> I'd be rather surprised if this is actually what you want to do. I'd
> expect you to set the map directly on the JMS ObjectMessage, and then
> thanks to the special flag the client will encode it itself as an
> amqp-value section containing a map (which now that ive kept reading,
> matches what you are attempting with proton-j).
>
> >
> > Second, I tried with Proton-j (attached code):
> > The code i wrote is based on send example in proton-j.
> > But the problem is that i am not able to find how to set the destination
> > queue of the message. (i used Message.setAddress() but it is wrong)
> >
> > How can i set a destination queue for the sender or message?
>
> To give the link an addres you need to set the link 'source' and
> 'target' and use the latter to indicate the address for the sending
> link before you open it. E.g for address "queue", the most basic
> config would be:
>
> + Target target = new Target();
> + target.setAddress("queue");
> + snd.setTarget(target );
> + snd.setSource(new Source());
>
>
> >
> > PS. I used wireshark to see the amqp messages that are passing on the
> > network and copy the message parameters.
> >
> >
> > Best Regards,
> > Rabih
> >
> > On Wed, Jan 18, 2017 at 2:35 PM, Rob Godfrey <ro...@gmail.com>
> > wrote:
> >>
> >> So I think what we said - and I can't find it written down anywhere in
> the
> >> draft, though we reference the JSON spec in the pre-amble, is that any
> >> value in the headers or body should be able to be sent in the native
> AMQP
> >> type (and we might need some words there about converting between
> various
> >> numeric types), or as a JSON serialized string. We didn't (to my
> >> recollection) talk about whether there should be a way for the requester
> >> to
> >> be able to influence the form of the reply.
> >>
> >> Currently the implementation of AMQP Management in the Qpid Broker for
> >> Java
> >> follows the above conventions (any inbound value can be in the native
> >> type,
> >> or as a JSON string which can convert to the desired type, however there
> >> is
> >> no mechanism for controlling the nature of responses).
> >>
> >> Perhaps this is something we should talk about soon ;-) ?
> >>
> >> -- Rob
> >>
> >> On 18 January 2017 at 14:29, Ted Ross <tr...@redhat.com> wrote:
> >>
> >> >
> >> >
> >> > On 01/18/2017 07:45 AM, Gordon Sim wrote:
> >> >
> >> >> On 18/01/17 10:45, Rob Godfrey wrote:
> >> >>
> >> >>> In terms of sending maps/lists I think we said (at OASIS), though it
> >> >>> is
> >> >>> possibly not yet in the draft spec, that Json formatted equivalents
> >> >>> should
> >> >>> be able to be used for all values... however I have no idea if the
> >> >>> Dispatch
> >> >>> Router supports that.
> >> >>>
> >> >>
> >> >> I think that would be very sensible.
> >> >>
> >> >
> >> > Dispatch Router does not support Json formatted bodies at present, but
> >> > this is a feature that I would be in favor of putting on the roadmap.
> >> >
> >> >
> >> >
> >> >>
> >> >> ------------------------------------------------------------
> ---------
> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>
> >> >>
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> > For additional commands, e-mail: users-help@qpid.apache.org
> >> >
> >> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Robbie Gemmell <ro...@gmail.com>.
On 20 January 2017 at 17:29, Rabih M <ra...@gmail.com> wrote:
> Hello,
>
> Thank you for you answers.
>
> I am trying to experiment to see if i can do it with the info you gave me.
>
> I took a simple example to start: qdmanage -b <dispatch-machine>:5672 create
> --type=connector role=route-container addr=broker-machine port=5673
> name=rabih.connector
> My goal is to imitate the behavior using JMS and Proton-j.
>
> First, I tried with JMS (attached the code):
> I used an ObjectMessage with JMS_AMQP_TYPED_ENCODING set to true. And I used
> the proton-j encoder to encode the map before sending it.
> But, I am getting a MessageFormatException("Failed to serialize object")
>
> Do you have any idea how can i pass the byte array without failing?
>
I'd be rather surprised if this is actually what you want to do. I'd
expect you to set the map directly on the JMS ObjectMessage, and then
thanks to the special flag the client will encode it itself as an
amqp-value section containing a map (which now that ive kept reading,
matches what you are attempting with proton-j).
>
> Second, I tried with Proton-j (attached code):
> The code i wrote is based on send example in proton-j.
> But the problem is that i am not able to find how to set the destination
> queue of the message. (i used Message.setAddress() but it is wrong)
>
> How can i set a destination queue for the sender or message?
To give the link an addres you need to set the link 'source' and
'target' and use the latter to indicate the address for the sending
link before you open it. E.g for address "queue", the most basic
config would be:
+ Target target = new Target();
+ target.setAddress("queue");
+ snd.setTarget(target );
+ snd.setSource(new Source());
>
> PS. I used wireshark to see the amqp messages that are passing on the
> network and copy the message parameters.
>
>
> Best Regards,
> Rabih
>
> On Wed, Jan 18, 2017 at 2:35 PM, Rob Godfrey <ro...@gmail.com>
> wrote:
>>
>> So I think what we said - and I can't find it written down anywhere in the
>> draft, though we reference the JSON spec in the pre-amble, is that any
>> value in the headers or body should be able to be sent in the native AMQP
>> type (and we might need some words there about converting between various
>> numeric types), or as a JSON serialized string. We didn't (to my
>> recollection) talk about whether there should be a way for the requester
>> to
>> be able to influence the form of the reply.
>>
>> Currently the implementation of AMQP Management in the Qpid Broker for
>> Java
>> follows the above conventions (any inbound value can be in the native
>> type,
>> or as a JSON string which can convert to the desired type, however there
>> is
>> no mechanism for controlling the nature of responses).
>>
>> Perhaps this is something we should talk about soon ;-) ?
>>
>> -- Rob
>>
>> On 18 January 2017 at 14:29, Ted Ross <tr...@redhat.com> wrote:
>>
>> >
>> >
>> > On 01/18/2017 07:45 AM, Gordon Sim wrote:
>> >
>> >> On 18/01/17 10:45, Rob Godfrey wrote:
>> >>
>> >>> In terms of sending maps/lists I think we said (at OASIS), though it
>> >>> is
>> >>> possibly not yet in the draft spec, that Json formatted equivalents
>> >>> should
>> >>> be able to be used for all values... however I have no idea if the
>> >>> Dispatch
>> >>> Router supports that.
>> >>>
>> >>
>> >> I think that would be very sensible.
>> >>
>> >
>> > Dispatch Router does not support Json formatted bodies at present, but
>> > this is a feature that I would be in favor of putting on the roadmap.
>> >
>> >
>> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> For additional commands, e-mail: users-help@qpid.apache.org
>> >>
>> >>
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: users-help@qpid.apache.org
>> >
>> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Rabih M <ra...@gmail.com>.
Hello,
Thank you for you answers.
I am trying to experiment to see if i can do it with the info you gave me.
I took a simple example to start: qdmanage -b <dispatch-machine>:5672
create --type=connector role=route-container addr=broker-machine port=5673
name=rabih.connector
My goal is to imitate the behavior using JMS and Proton-j.
First, I tried with JMS (attached the code):
I used an ObjectMessage with JMS_AMQP_TYPED_ENCODING set to true. And I
used the proton-j encoder to encode the map before sending it.
But, I am getting a MessageFormatException("Failed to serialize object")
Do you have any idea how can i pass the byte array without failing?
Second, I tried with Proton-j (attached code):
The code i wrote is based on send example in proton-j.
But the problem is that i am not able to find how to set the destination
queue of the message. (i used Message.setAddress() but it is wrong)
How can i set a destination queue for the sender or message?
PS. I used wireshark to see the amqp messages that are passing on the
network and copy the message parameters.
Best Regards,
Rabih
On Wed, Jan 18, 2017 at 2:35 PM, Rob Godfrey <ro...@gmail.com>
wrote:
> So I think what we said - and I can't find it written down anywhere in the
> draft, though we reference the JSON spec in the pre-amble, is that any
> value in the headers or body should be able to be sent in the native AMQP
> type (and we might need some words there about converting between various
> numeric types), or as a JSON serialized string. We didn't (to my
> recollection) talk about whether there should be a way for the requester to
> be able to influence the form of the reply.
>
> Currently the implementation of AMQP Management in the Qpid Broker for Java
> follows the above conventions (any inbound value can be in the native type,
> or as a JSON string which can convert to the desired type, however there is
> no mechanism for controlling the nature of responses).
>
> Perhaps this is something we should talk about soon ;-) ?
>
> -- Rob
>
> On 18 January 2017 at 14:29, Ted Ross <tr...@redhat.com> wrote:
>
> >
> >
> > On 01/18/2017 07:45 AM, Gordon Sim wrote:
> >
> >> On 18/01/17 10:45, Rob Godfrey wrote:
> >>
> >>> In terms of sending maps/lists I think we said (at OASIS), though it is
> >>> possibly not yet in the draft spec, that Json formatted equivalents
> >>> should
> >>> be able to be used for all values... however I have no idea if the
> >>> Dispatch
> >>> Router supports that.
> >>>
> >>
> >> I think that would be very sensible.
> >>
> >
> > Dispatch Router does not support Json formatted bodies at present, but
> > this is a feature that I would be in favor of putting on the roadmap.
> >
> >
> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Rob Godfrey <ro...@gmail.com>.
So I think what we said - and I can't find it written down anywhere in the
draft, though we reference the JSON spec in the pre-amble, is that any
value in the headers or body should be able to be sent in the native AMQP
type (and we might need some words there about converting between various
numeric types), or as a JSON serialized string. We didn't (to my
recollection) talk about whether there should be a way for the requester to
be able to influence the form of the reply.
Currently the implementation of AMQP Management in the Qpid Broker for Java
follows the above conventions (any inbound value can be in the native type,
or as a JSON string which can convert to the desired type, however there is
no mechanism for controlling the nature of responses).
Perhaps this is something we should talk about soon ;-) ?
-- Rob
On 18 January 2017 at 14:29, Ted Ross <tr...@redhat.com> wrote:
>
>
> On 01/18/2017 07:45 AM, Gordon Sim wrote:
>
>> On 18/01/17 10:45, Rob Godfrey wrote:
>>
>>> In terms of sending maps/lists I think we said (at OASIS), though it is
>>> possibly not yet in the draft spec, that Json formatted equivalents
>>> should
>>> be able to be used for all values... however I have no idea if the
>>> Dispatch
>>> Router supports that.
>>>
>>
>> I think that would be very sensible.
>>
>
> Dispatch Router does not support Json formatted bodies at present, but
> this is a feature that I would be in favor of putting on the roadmap.
>
>
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Ted Ross <tr...@redhat.com>.
On 01/18/2017 07:45 AM, Gordon Sim wrote:
> On 18/01/17 10:45, Rob Godfrey wrote:
>> In terms of sending maps/lists I think we said (at OASIS), though it is
>> possibly not yet in the draft spec, that Json formatted equivalents
>> should
>> be able to be used for all values... however I have no idea if the
>> Dispatch
>> Router supports that.
>
> I think that would be very sensible.
Dispatch Router does not support Json formatted bodies at present, but
this is a feature that I would be in favor of putting on the roadmap.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Gordon Sim <gs...@redhat.com>.
On 18/01/17 10:45, Rob Godfrey wrote:
> In terms of sending maps/lists I think we said (at OASIS), though it is
> possibly not yet in the draft spec, that Json formatted equivalents should
> be able to be used for all values... however I have no idea if the Dispatch
> Router supports that.
I think that would be very sensible.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Gordon Sim <gs...@redhat.com>.
On 18/01/17 11:49, Robbie Gemmell wrote:
> On 18 January 2017 at 10:45, Rob Godfrey <ro...@gmail.com> wrote:
>> In terms of sending maps/lists I think we said (at OASIS), though it is
>> possibly not yet in the draft spec, that Json formatted equivalents should
>> be able to be used for all values... however I have no idea if the Dispatch
>> Router supports that.
>>
>
> To be clear, the above is in regard to the AMQP Management spec. I'll
> assume for now that Dispatch does not support a Json encoding.
Correct it does not (and the draft of the spec I linked to does not
mention it either, not sure if there is a later draft that does).
> Assuming that is the case, and that it won't quickly do so, the main
> issue currently would be sending AMQP encoded maps and lists from the
> JMS client to satisfy the content of the AMQP management messages the
> router expects. While the clients MapMessages do use an AMQP encoded
> map for its content, there are restrictions on its content in line
> with the JMS spec, restrictions which I think the AMQP management spec
> goes beyond.
Actually, for at least some uses, this would probably be enough. A
CREATE message takes a map as the body, specifying the attribute values.
Provided these were all simple types - which for the router all would be
except for policy related attributes - you might be ok. A DELETE body is
an empty map which should be no problem. A QUERY can take a map with a
single entry with key attributeNames and a value of a list of names.
That would I think violate the JMS MapMessage restrictions. However you
can just leave the body as an empty map and get all the attributes back.
> As Gordon mentioned, there is currently some undocumented
> functionality in the client which would allow it to send more
> generalised maps/lists encoded using the AMQP type system. If you set
> the "JMS_AMQP_TYPED_ENCODING" boolean property to true on the clients
> ObjectMessage (preferably before setting the Serializable body object)
> its content will be encoded using the AMQP type system when sent
> rather than as the output from an ObjectOutputStream as they normally
> would be. Obligatory warning: this remains undocumented for good
> reason, being incomplete and subject to change, though whats there
> currently should work for Maps/Lists as needed here.
>
>> In terms of receiving lists / maps I would assume that treating the
>> received JMS Message as an ObjectMessage and casting that result to the
>> correct type (List or Map as appropriate) will always work? Though I
>> should probably wait for Robbie to step in on this one :-)
>
> Yes, the received messages would be expected to turn up as
> ObjectMessage in this case, and then you would need to treat the
> content appropriately as e.g a Map/List.
Ok, so in that case I should correct my original response and say that a
reasonable amount of management of the router *could* most likely be
achieved using JMS at present. No one has done so yet though, as far as
I'm aware.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Robbie Gemmell <ro...@gmail.com>.
On 18 January 2017 at 10:45, Rob Godfrey <ro...@gmail.com> wrote:
> In terms of sending maps/lists I think we said (at OASIS), though it is
> possibly not yet in the draft spec, that Json formatted equivalents should
> be able to be used for all values... however I have no idea if the Dispatch
> Router supports that.
>
To be clear, the above is in regard to the AMQP Management spec. I'll
assume for now that Dispatch does not support a Json encoding.
Assuming that is the case, and that it won't quickly do so, the main
issue currently would be sending AMQP encoded maps and lists from the
JMS client to satisfy the content of the AMQP management messages the
router expects. While the clients MapMessages do use an AMQP encoded
map for its content, there are restrictions on its content in line
with the JMS spec, restrictions which I think the AMQP management spec
goes beyond. As Gordon mentioned, there is currently some undocumented
functionality in the client which would allow it to send more
generalised maps/lists encoded using the AMQP type system. If you set
the "JMS_AMQP_TYPED_ENCODING" boolean property to true on the clients
ObjectMessage (preferably before setting the Serializable body object)
its content will be encoded using the AMQP type system when sent
rather than as the output from an ObjectOutputStream as they normally
would be. Obligatory warning: this remains undocumented for good
reason, being incomplete and subject to change, though whats there
currently should work for Maps/Lists as needed here.
> In terms of receiving lists / maps I would assume that treating the
> received JMS Message as an ObjectMessage and casting that result to the
> correct type (List or Map as appropriate) will always work? Though I
> should probably wait for Robbie to step in on this one :-)
>
> -- Rob
Yes, the received messages would be expected to turn up as
ObjectMessage in this case, and then you would need to treat the
content appropriately as e.g a Map/List.
>
> On 18 January 2017 at 11:39, Gordon Sim <gs...@redhat.com> wrote:
>
>> On 17/01/17 16:03, Rabih M wrote:
>>
>>> Hello,
>>>
>>> If I understood well, Qpid-Dispatch can be managed using Amqp messages.
>>> I saw that the management code is based on proton python binding.
>>>
>>> Do you think it is feasible to manage the dispatch router the same way
>>> from
>>> Qpid-Jms api?
>>>
>>
>> Yes, but only through an undocumented mechanism that is subject to change
>> at present. The issue is that it requires sending/receiving AMQP encoded
>> lists and maps which is not properly supported yet via the JMS API.
>>
>> Was there any work done in this direction before? Will it be too
>>> complicated to do it?
>>>
>>
>> The protocol is based on the draft of a 'management spec' from OASIS[1].
>> In general it is very easy to use as long as you can handle AMQP encoded
>> list and map content.
>>
>> The router has its own specific entities which are described (though from
>> the config file perspective) here:
>>
>> http://qpid.apache.org/releases/qpid-dispatch-0.6.0/man/
>> qdrouterd.conf.html
>>
>> The qdmanage tool is very useful for exploring things (e.g. GET-SCHEMA
>> etc).
>>
>> [1] https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web
>> &cd=1&cad=rja&uact=8&ved=0ahUKEwjnzIC-vcvRAhVn0YMKHTvABMEQFg
>> gfMAA&url=https%3A%2F%2Fwww.oasis-open.org%2Fcommittees%2F
>> download.php%2F52425%2Famqp-man-v1%25200-wd08.pdf&usg=AFQjCN
>> EDHTcSb8gSA2Uqx-bAkupHHcn92A
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Rob Godfrey <ro...@gmail.com>.
In terms of sending maps/lists I think we said (at OASIS), though it is
possibly not yet in the draft spec, that Json formatted equivalents should
be able to be used for all values... however I have no idea if the Dispatch
Router supports that.
In terms of receiving lists / maps I would assume that treating the
received JMS Message as an ObjectMessage and casting that result to the
correct type (List or Map as appropriate) will always work? Though I
should probably wait for Robbie to step in on this one :-)
-- Rob
On 18 January 2017 at 11:39, Gordon Sim <gs...@redhat.com> wrote:
> On 17/01/17 16:03, Rabih M wrote:
>
>> Hello,
>>
>> If I understood well, Qpid-Dispatch can be managed using Amqp messages.
>> I saw that the management code is based on proton python binding.
>>
>> Do you think it is feasible to manage the dispatch router the same way
>> from
>> Qpid-Jms api?
>>
>
> Yes, but only through an undocumented mechanism that is subject to change
> at present. The issue is that it requires sending/receiving AMQP encoded
> lists and maps which is not properly supported yet via the JMS API.
>
> Was there any work done in this direction before? Will it be too
>> complicated to do it?
>>
>
> The protocol is based on the draft of a 'management spec' from OASIS[1].
> In general it is very easy to use as long as you can handle AMQP encoded
> list and map content.
>
> The router has its own specific entities which are described (though from
> the config file perspective) here:
>
> http://qpid.apache.org/releases/qpid-dispatch-0.6.0/man/
> qdrouterd.conf.html
>
> The qdmanage tool is very useful for exploring things (e.g. GET-SCHEMA
> etc).
>
> [1] https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web
> &cd=1&cad=rja&uact=8&ved=0ahUKEwjnzIC-vcvRAhVn0YMKHTvABMEQFg
> gfMAA&url=https%3A%2F%2Fwww.oasis-open.org%2Fcommittees%2F
> download.php%2F52425%2Famqp-man-v1%25200-wd08.pdf&usg=AFQjCN
> EDHTcSb8gSA2Uqx-bAkupHHcn92A
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Posted by Gordon Sim <gs...@redhat.com>.
On 17/01/17 16:03, Rabih M wrote:
> Hello,
>
> If I understood well, Qpid-Dispatch can be managed using Amqp messages.
> I saw that the management code is based on proton python binding.
>
> Do you think it is feasible to manage the dispatch router the same way from
> Qpid-Jms api?
Yes, but only through an undocumented mechanism that is subject to
change at present. The issue is that it requires sending/receiving AMQP
encoded lists and maps which is not properly supported yet via the JMS API.
> Was there any work done in this direction before? Will it be too
> complicated to do it?
The protocol is based on the draft of a 'management spec' from OASIS[1].
In general it is very easy to use as long as you can handle AMQP encoded
list and map content.
The router has its own specific entities which are described (though
from the config file perspective) here:
http://qpid.apache.org/releases/qpid-dispatch-0.6.0/man/qdrouterd.conf.html
The qdmanage tool is very useful for exploring things (e.g. GET-SCHEMA etc).
[1]
https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjnzIC-vcvRAhVn0YMKHTvABMEQFggfMAA&url=https%3A%2F%2Fwww.oasis-open.org%2Fcommittees%2Fdownload.php%2F52425%2Famqp-man-v1%25200-wd08.pdf&usg=AFQjCNEDHTcSb8gSA2Uqx-bAkupHHcn92A
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org