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