Hi all Thanks for the informative and very helpful responses.
We did look at qpid:Messaging but this seems to be separate from the qpid-proton library, and there is a concern that the is no Java API and some of the function we require is missing. Our server backend is built on the qpid-proton library so ideally we would like our client API to also be built using qpid-proton library function. As an aside, why is the qpid::messaging alternative API part of qpid rather than the qpid-proton package? Is there a specific reason why it wasn't built on top of the qpid-proton engine? The qpid-proton Messenger seems to give us the functionality that we require, except connect. So I can think of three options for the way forward: Write our API based on the qpid-proton engine directly. Have a qpid:Messaging like API be built on the qpid-proton engine, and we implement our API based on that. See if we can't win you around to the idea of adopting the addition of a pn_messenger_test_connection function at the Messenger API, as opposed to the original idea of a pn_messenger_connect function. This would then enable client applications to fail fast if the supplied connection details were invalid. With the experience of the community what would you recommend? Thanks Chris -------------------------------------------------------------------------- Chris White WebSphere MQ File Transfer Technologies 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 -------------------------------------------------------------------------- From: Rafael Schloming <r...@alum.mit.edu> To: "proton@qpid.apache.org" <proton@qpid.apache.org>, Date: 22/04/2014 21:05 Subject: Re: Using the messenger API to connect to a server without sending or subscribing Hi Chris, Sorry for chiming in late, I've been in and out of meetings all day. Comments are inline... On Tue, Apr 22, 2014 at 2:49 AM, Chris White1 <chris.wh...@uk.ibm.com>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. > As Fraser mentioned in his reply, part of the idea behind Messenger is to be Message oriented as opposed to Connection oriented. One of the key requirements behind this is the idea that you should be able to change the topology of the physical connections in use without having any impact on the application itself. For example, say a typical JMS application is coded to interact with 3 or 4 different queues. If any of those queues are moved to a different broker, more often than not you would probably need to recode the JMS application. For a Messenger app though you simply adjust the addresses in use and no code changes are necessary. This is just one example of how that flexibility is useful, and there are a lot of other possibilities, most of which aren't implemented yet, but which I don't want to preclude. Things like: - automatic reconnect - automatically reclaiming idle connections - having messenger manage redundant pathways (useful for things that are traditionally done with failover and load balancing in the broker) - peer to peer operation - server operation - disconnected operation - client side persistence All that said, I completely buy that it would be nice to be able to fail fast in certain scenarios (as Dominic points out in his email), and if we can find a way to do that without necessarily surfacing connections so directly then I'm all for it. > > 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 don't know if you've looked at pn_messenger_route at all, but it might be possible for pn_messenger_start to optionally resolve any specified routes. This might provide some of what you're looking for. > > 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. > As I said above it makes sense to me from a fail fast perspective in some scenarios, but I would think you would want to be able to explicitly control it. For example if I've got a typo in my hostname I want to find out about it right when I start the client as opposed to later on, but if I want my client to be able to operate in disconnected mode then the fact that I can't connect to a given host doesn't necessarily mean it is invalid, and in that case the correct behaviour might be to just locally queue the message and wait for connectivity to return. --Rafael 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
