Re: CorrelationId

2014-10-08 Thread xavier
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 + ');
consumer-start();

But with qpid proton and messenger, if I do that:
I get the response, and I does not accept it, if the correlationId recieve,
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 too. 

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

pn_selectable_t ??
pn_selector_t 

Thank you

Xav




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


Re: CorrelationId

2014-10-08 Thread Fraser Adams

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 + ');
consumer-start();

But with qpid proton and messenger, if I do that:
I get the response, and I does not accept it, if the correlationId recieve,
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 too.

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

pn_selectable_t ??
pn_selector_t 

Thank you

Xav




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


Re:

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

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/MessageConsumer.html|
|*createConsumer  
http://docs.oracle.com/javaee/5/api/javax/jms/Session.html#createConsumer%28javax.jms.Destination,%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 
https://svn.apache.org/repos/asf/qpid/trunk/qpid/specs/apache-filters.xml#type-selector-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: 
\correlation_id='mycid'\}}


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 

Re: CorrelationId

2014-10-08 Thread Rafael Schloming
On Wed, Oct 8, 2014 at 1:30 PM, Fraser Adams fraser.ad...@blueyonder.co.uk
wrote:

 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 + ');
 consumer-start();

 But with qpid proton and messenger, if I do that:
 I get the response, and I does not accept it, if the correlationId
 recieve,
 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
 too.

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

 pn_selectable_t ??
 pn_selector_t 

 Thank you

 Xav




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


 Re:

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

 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/
 MessageConsumer.html|
 |*createConsumer  http://docs.oracle.com/javaee/5/api/javax/jms/
 Session.html#createConsumer%28javax.jms.Destination,%
 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
 https://svn.apache.org/repos/asf/qpid/trunk/qpid/specs/
 apache-filters.xml#type-selector-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:
 \correlation_id='mycid'\}}


 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 

Re: CorrelationId

2014-10-08 Thread Fraser Adams

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


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 + ');
consumer-start();

But with qpid proton and messenger, if I do that:
I get the response, and I does not accept it, if the correlationId
recieve,
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
too.

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

pn_selectable_t ??
pn_selector_t 

Thank you

Xav




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


Re:

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

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/
MessageConsumer.html|
|*createConsumer  http://docs.oracle.com/javaee/5/api/javax/jms/
Session.html#createConsumer%28javax.jms.Destination,%
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
https://svn.apache.org/repos/asf/qpid/trunk/qpid/specs/
apache-filters.xml#type-selector-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:
\correlation_id='mycid'\}}


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