qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris White1 <Chris.Wh...@uk.ibm.com>
Subject Re: Using the messenger API to connect to a server without sending or subscribing
Date Wed, 23 Apr 2014 14:51:26 GMT
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.white@uk.ibm.com
--------------------------------------------------------------------------



From:   Rafael Schloming <rhs@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.White@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message