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
