Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms

Ted Ross Mon, 06 Feb 2017 10:00:02 -0800


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 bugassociated 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 whatto 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 <adelbout...@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 <robbie.gemm...@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 <rabih.prom...@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.gemm...@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 <rabih.prom...@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.godf...@gmail.com>
wrote:


On 20 January 2017 at 21:45, Ganesh Murthy <gmur...@redhat.com>
wrote:


----- Original Message -----

From: "Robbie Gemmell" <robbie.gemm...@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 <g...@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-unsubscr...@qpid.apache.org

For additional commands, e-mail: users-h...@qpid.apache.org

------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms

Reply via email to