On 08/10/14 18:49, Rafael Schloming wrote:
On Wed, Oct 8, 2014 at 1:30 PM, Fraser Adams <fraser.ad...@blueyonder.co.uk>

On 08/10/14 08:16, xavier wrote:

Hi Frase,

Thanks for your explanation, but here, my code:

In the requester:

char * corrId;
pn_bytes_t bytes  = pn_bytes(correlationId.size(), corrId);
pn_atom_t id;
id.type = PN_STRING;
id.u.as_bytes = bytes;
pn_message_set_correlation_id(message, id);

and after, send it
pn_messenger_put(messengerProducer, message);

I see on the broker, the correlationId is correctly setted, so no pb.

after I wait the answer, but I would like (like JMS) only wake up on an
answer at my question (and the correlationId is here to do that)

in CMS

MessageConsumer* consumer = session->createConsumer(destination,
"JMSCorrelationID='" + correlationId + "'");

But with qpid proton and messenger, if I do that:
I get the response, and I does not accept it, if the correlationId
is not the good one, but for me, it's not a good practice, because we
retrieve the message (network traffic) in right case, but in wrong case

So I would like to the same things like CMS, but.... how????

pn_selectable_t ??????????
pn_selector_t ????????????

Thank you


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


MessageConsumer* consumer = session->createConsumer(destination,
"JMSCorrelationID='" + correlationId + "'");

That's exactly the bit that I've been trying to explain is the complicated
bit, and the bit that Robbie referred to in his previous reply.

In JMS and I guess with CMS that syntax means:

|  MessageConsumer  <http://docs.oracle.com/javaee/5/api/javax/jms/
|*createConsumer  <http://docs.oracle.com/javaee/5/api/javax/jms/
20java.lang.String,%20boolean%29>*(Destination  <http://docs.oracle.com/
javaee/5/api/javax/jms/Destination.html>  destination,
                String  <http://java.sun.com/j2se/1.5/
docs/api/java/lang/String.html>  messageSelector,
                boolean NoLocal)|

           Creates|MessageConsumer|  for the specified destination, using a
  message selector.

At an API level it's nice and simple, but there's a lot going on under the
hood and what it's doing is to pass information on the AMQP link attach (I
think) that configures a Message Selector (which is and AMQP filter

Unfortunately (and I'd agree somewhat annoyingly!!) proton Messenger does
not yet support this type of sophistication when specifying subscriptions,
I wish it did myself, but unfortunately it currently does not :-(

The stuff:
pn_selectable_t ??????????
pn_selector_t ????????????

Relates to something completely different I'm afraid those are actually
related to low level socket selectors (i.e. more related to the
select/poll/epoll system calls than Message Selectors). Their main use is
for replacing Messenger's internal network event loop so it can be more
easily integrated with other applications.

I can't recall why you said you were using Messenger specifically, If you
can use C++ (rather than C) you might want to look at the qpid::messaging
API, you can definitely do the sort of thing that you want (e.g. using the
broker to perform filtering based on CorrelationID) using qpid::messaging.
The syntax is a little different in that I don't believe that there's a
particular overloaded createConsumer method call to set a selector and
you'd have to do it in the Address String - it'd look *something* like the
following (I think, I've not tried it YMMV) BTW if you haven't come across
it drain is a little qpid demo application that's really useful for trying
out Address Strings. So if you have a queue called queue1 this should
filter on messages with a given correlation ID.

./drain -b localhost -f \
"queue1; {create: receiver, link: {name: test-link, selector:

That's the sort of syntax I'd like to see supported for Messenger
Subscriptions too (but as I say it currently isn't).

I've copied my response to the qpid users mailing list, I tend to
recommend that people post questions there as it tends to have a broader
readership than the proton one.

If you have to use C (as opposed to C++) then as I say Messenger won't do
what you want (though clearly you could do your own filtering inside your
consumer/server client), you could also get a bit more low-level and use
the Engine API, which will allow the sort of thing that you want
(qpid::messaging actually uses the proton Engine API under the hood), but
I'm afraid that I couldn't help you make any progress using Engine as I've
not got round to playing with that myself yet.

Sorry I can't give you a simple answer to your question, hopefully my
explanation of the reasons why is better than it was previously.

In short:
* You can't currently do message selectors/filters with Messenger
* You can do this with JMS and qpid::messaging but the latter is C++ not C
* You can do it with the Engine API, but I couldn't tell you how to (if
you look in the qpid::messaging source you should get a good idea - that's
where I'd start)

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.


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.


Reply via email to