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
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
With the experience of the community what would you recommend?
WebSphere MQ File Transfer Technologies
IBM United Kingdom Limited
Winchester , England
Tel: +44 (0)1962 818209 (Ext) or 37248209 (Int)
From: Rafael Schloming <r...@alum.mit.edu>
To: "email@example.com" <firstname.lastname@example.org>,
Date: 22/04/2014 21:05
Subject: Re: Using the messenger API to connect to a server without
sending or subscribing
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
> 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
> perform a connect, without sending a message or subscribing to receive
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
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
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.
> 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
possible for pn_messenger_start to optionally resolve any specified
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
> 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
> before they are ready to send or receive messages. Also a connect
> 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
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.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU