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