On Thu, Oct 9, 2014 at 8:44 AM, Dominic Evans <dominic.ev...@uk.ibm.com>
wrote:

> fadams wrote
> > On 08/10/14 18:49, Rafael Schloming wrote:
> >> Actually I think it is possible to do this with messenger now that
> >> dominic's patches are in. You can access the link associated with any
> >> given
> >> address using pn_messenger_get_link() and configure it however you want
> >> to.
> >>
> >> --Rafael
> >>
> > Oooh now there's a thought Rafi, I was wondering if Dominic's patches
> > might open up that possibility but I didn't really know enough about the
> > link API to be sure.
> >
> > Don't suppose that you have any code snippets that could help out?
> >
> > Presumably the main call is the recently added
> >
> > pn_messenger_get_link(pn_messenger_t *messenger,
> >                                             const char *address, bool
> > sender)
> >
> >
> > I'm not clear at which point you'd need to "fiddle" with it, so for
> > example I'd normally do a subscribe, so would I first do a subscribe and
> > then immediately do a pn_messenger_get_link using the same address as
> > the source used for the subscription?
> >
> > I'm afraid I'm a bit ignorant in all this 'cause I'd have assumed that
> > you'd need to specify things like filters/selectors before the link
> > attach occurs, but I wasn't clear that you had control of that in
> > Messenger, as I say all I've done has been fairly basic things like
> > subscribe followed by a check on incoming followed by a get.
> >
> > Some code (or even pseudocode) would be really useful.
> >
> > Frase
>
> So for me, pn_messenger_get_link was only really intended for interrogating
> the status of a link (e.g., checking if its ACTIVE or CLOSED) or
> (post-attach) for modifying the time-to-live before closing it.
>
> So e.g.,
>
>   pn_link_t* link =
>       pn_messenger_get_link(messenger, address, false); // get recv link
>   pn_terminus_set_timeout(pn_link_target(link), ttl);
>   pn_link_close(link);
>
> Afaik the interpretation of AMQP filters is entirely broker specific?
> Either
> way I expect that the broker will expect it be sent as part of the initial
> @attach. You *could* try modifying the pn_data_t returned by
> pn_terminus_filter and then doing a pn_link_close immediately followed by a
> pn_link_open.
>

I haven't tried this, but I think so long as you access and modify the link
just after the initial subscribe that creates it, you shouldn't need to
close/reopen it because the initial attach won't have happened yet and any
filter you put on the link should get sent later on when it does happen.


> Alternatively extend pn_messenger_subscribe to allow you to specify a
> filter
> up-front before the first attach.
>

Yes, or equivalently add a pn_subscription_set_filter to allow the returned
subscription to be modified. It should be pretty straightforward to do
either one. I haven't had time personally but I would welcome the
contribution. ;-)

--Rafael



>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/CorrelationId-tp7614606p7614830.html
> Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
>

Reply via email to