On Wed, Apr 23, 2014 at 10:51 AM, Chris White1 <chris.wh...@uk.ibm.com>wrote:

> 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::messaging API actually predates proton. It was originally
implemented over the 0-10 version of the protocol. The 1.0 implementation
does in fact use the proton engine, however the dependencies make it
difficult to separate from the cpp broker.

> 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?

My inclination would be to add some sort of policy or mode to messenger.
I'm not sure what I'd call it, but with this mode enabled, messenger (when
started) would always maintain active connections and/or links to any
declared routes. I think this is a bit more flexible than just the ability
to test a connection because a route can include the node information as
well. This would, e.g. give you the option of failing fast not only if the
broker was down, but also if the queue doesn't exist. In the python binding
it would look something like this:

  messenger.blah_mode = True
  messenger.route("broker1/*", "broker1.foo.com/$1")
  messenger.route("queueA", "broker2.bar.com/queueA")
  messenger.start() # this would now blow up if broker1 or broker2 is
inaccessable, or if queueA doesn't exist.

Does this seem like it would cover your use case?


Reply via email to