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
