Using the messenger API to connect to a server without sending or subscribing
Hi I'm part of the IBM team developing MQ Light ( https://www.ibmdw.net/messaging/mq-light/) and we are implementing our client API using the AMQP Messenger C API. Our client API has a connect function, which is required to be invoked before sending or receiving messages. The AMQP Messager C API does not seem to have an API function to perform a connect, without sending a message or subscribing to receive messages. Looking at the messenger.c source code I found that function pn_messenger_resolve appears to give the connect behaviour we require. So could the pn_messenger_resolve be added to the API please (maybe with a different name, say: pn_messenger_connect, which seems more intuitive)? I was thinking that the pn_messenger_start function should eventually be doing the connect, but that does not take an address argument, so is probably not appropriate. I would also be interested in others opinions about this, as it may seem to be a strange thing to want to do, i.e. why would you want to connect if you're not going to send or receive messages? A use case for this could be that a server wants to be aware of active clients communicating with it before they are ready to send or receive messages. Also a connect function enables a client to determine if a server is available before exchanging data with it. Thanks Chris -- Chris White MP 211 IBM United Kingdom Limited Hursley Park Winchester , England SO21 2JN Tel: +44 (0)1962 818209 (Ext) or 37248209 (Int) E-mail: chris.wh...@uk.ibm.com -- Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Using the messenger API to connect to a server without sending or subscribing
I'm sure others with more detailed knowledge of the background would be able to give a better answer, but in short I think the thing that you need to bear in mind is that proton Messenger is a *Message* oriented API as opposed to a *Connection* oriented API, so for example compare the approach taken with Messenger with say the qpid::messaging API and JMS which are both Connection oriented APIs (where you specify Connection, Session etc.). Messenger is supposed to abstract the (client) user from needing to care about such things, so you specify the address that you want to send a Message to in the Message and let Messenger take care of the Connection and Session stuff. Of course for receiving messages Messenger does connect to the address given via pn_messenger_subscribe (though I'm not sure myself if it is on this call or the pn_messenger_recv call where the connection actually happens). I guess that both approaches have their own relative advantages and disadvantages and TBH I'm generally more familiar with the Connection oriented APIs myself. I think that you will likely just have to live with it, or if you can't then build your higher level API on top of qpid::messenger (which uses Proton engine under the hood when AMQP 1.0 is enabled) or build directly using the proton *Engine* API vice the Messenger API, though that'll take a bit more effort and energy and you'd likely want to look at the qpid::messaging implementation or the dispatch router code for how to talk engine directly (I've never braved using engine directly myself). Sorry it's probably not the answer you were looking for. Regards, Frase On 22/04/14 07:49, Chris White1 wrote: Hi I'm part of the IBM team developing MQ Light ( https://www.ibmdw.net/messaging/mq-light/) and we are implementing our client API using the AMQP Messenger C API. Our client API has a connect function, which is required to be invoked before sending or receiving messages. The AMQP Messager C API does not seem to have an API function to perform a connect, without sending a message or subscribing to receive messages. Looking at the messenger.c source code I found that function pn_messenger_resolve appears to give the connect behaviour we require. So could the pn_messenger_resolve be added to the API please (maybe with a different name, say: pn_messenger_connect, which seems more intuitive)? I was thinking that the pn_messenger_start function should eventually be doing the connect, but that does not take an address argument, so is probably not appropriate. I would also be interested in others opinions about this, as it may seem to be a strange thing to want to do, i.e. why would you want to connect if you're not going to send or receive messages? A use case for this could be that a server wants to be aware of active clients communicating with it before they are ready to send or receive messages. Also a connect function enables a client to determine if a server is available before exchanging data with it. Thanks Chris -- Chris White MP 211 IBM United Kingdom Limited Hursley Park Winchester , England SO21 2JN Tel: +44 (0)1962 818209 (Ext) or 37248209 (Int) E-mail: chris.wh...@uk.ibm.com -- Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
[VOTE]: Release Proton 0.7 RC4 as 0.7 final
Hi Everyone, I haven't heard of any issues in RC4, so I'm going to put this to a formal vote now: Source artifacts are here: - http://people.apache.org/~rhs/qpid-proton-0.7rc4/ Java binaries are here: - https://repository.apache.org/content/repositories/orgapacheqpid-1004/ Please review and register your vote: [ ] Yes, release 0.7 RC4 as 0.7 final [ ] No, 0.7 RC4 as the following issues... Thanks, --Rafael
[jira] [Commented] (PROTON-531) Expose the selectable and passive features of Messenger in Ruby
[ https://issues.apache.org/jira/browse/PROTON-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13976734#comment-13976734 ] ASF subversion and git services commented on PROTON-531: Commit 1589121 from [~mcpierce] in branch 'proton/trunk' [ https://svn.apache.org/r1589121 ] PROTON-531: Removed Selectable.killable? from Ruby bindings The API is unnecessary. Expose the selectable and passive features of Messenger in Ruby --- Key: PROTON-531 URL: https://issues.apache.org/jira/browse/PROTON-531 Project: Qpid Proton Issue Type: Improvement Components: ruby-binding Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Expose this functionality to improve performance on Ruby applications. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE]: Release Proton 0.7 RC4 as 0.7 final
[X] Yes, release 0.7 RC4 as 0.7 final [ ] No, 0.7 RC4 as the following issues... Regards, Frase
Re: [VOTE]: Release Proton 0.7 RC4 as 0.7 final
+1 On 04/22/2014 07:12 AM, Rafael Schloming wrote: Hi Everyone, I haven't heard of any issues in RC4, so I'm going to put this to a formal vote now: Source artifacts are here: - http://people.apache.org/~rhs/qpid-proton-0.7rc4/ Java binaries are here: - https://repository.apache.org/content/repositories/orgapacheqpid-1004/ Please review and register your vote: [ ] Yes, release 0.7 RC4 as 0.7 final [ ] No, 0.7 RC4 as the following issues... Thanks, --Rafael
Re: [VOTE]: Release Proton 0.7 RC4 as 0.7 final
+1 Robbie On 22 Apr 2014 12:13, Rafael Schloming r...@alum.mit.edu wrote: Hi Everyone, I haven't heard of any issues in RC4, so I'm going to put this to a formal vote now: Source artifacts are here: - http://people.apache.org/~rhs/qpid-proton-0.7rc4/ Java binaries are here: - https://repository.apache.org/content/repositories/orgapacheqpid-1004/ Please review and register your vote: [ ] Yes, release 0.7 RC4 as 0.7 final [ ] No, 0.7 RC4 as the following issues... Thanks, --Rafael
Re: [VOTE]: Release Proton 0.7 RC4 as 0.7 final
[X] Yes, release 0.7 RC4 as 0.7 final [ ] No, 0.7 RC4 as the following issues... - Original Message - From: Robbie Gemmell robbie.gemm...@gmail.com To: proton@qpid.apache.org Sent: Tuesday, April 22, 2014 11:04:04 AM Subject: Re: [VOTE]: Release Proton 0.7 RC4 as 0.7 final +1 Robbie On 22 Apr 2014 12:13, Rafael Schloming r...@alum.mit.edu wrote: Hi Everyone, I haven't heard of any issues in RC4, so I'm going to put this to a formal vote now: Source artifacts are here: - http://people.apache.org/~rhs/qpid-proton-0.7rc4/ Java binaries are here: - https://repository.apache.org/content/repositories/orgapacheqpid-1004/ Please review and register your vote: [ ] Yes, release 0.7 RC4 as 0.7 final [ ] No, 0.7 RC4 as the following issues... Thanks, --Rafael -- -K
Re: [VOTE]: Release Proton 0.7 RC4 as 0.7 final
fwiw, [X] Yes, release 0.7 RC4 as 0.7 final [ ] No, 0.7 RC4 as the following issues... Bozzo On 22. 04. 14 13:12, Rafael Schloming wrote: Hi Everyone, I haven't heard of any issues in RC4, so I'm going to put this to a formal vote now: Source artifacts are here: - http://people.apache.org/~rhs/qpid-proton-0.7rc4/ Java binaries are here: - https://repository.apache.org/content/repositories/orgapacheqpid-1004/ Please review and register your vote: [ ] Yes, release 0.7 RC4 as 0.7 final [ ] No, 0.7 RC4 as the following issues... Thanks, --Rafael
Re: Using the messenger API to connect to a server without sending or subscribing
undefined
Re: Using the messenger API to connect to a server without sending or subscribing
undefined
[jira] [Updated] (PROTON-558) Make friendly protocol field logging optional for low-memory devices
[ https://issues.apache.org/jira/browse/PROTON-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Horstmann updated PROTON-558: Affects Version/s: 0.7 Make friendly protocol field logging optional for low-memory devices Key: PROTON-558 URL: https://issues.apache.org/jira/browse/PROTON-558 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.6, 0.7 Reporter: Markus Horstmann Embedded devices tend to be memory constrained (i.e. 128KB RAM). The FIELDS structure used for protocol logging consumes significant memory. Making it optional would help reduce the memory footprint. -- This message was sent by Atlassian JIRA (v6.2#6252)
