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