qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Quinn <fquinn...@gmail.com>
Subject Alternatives to pn_messenger (QPID Proton C)
Date Wed, 03 May 2017 07:55:40 GMT
Hi Folks,

I look after the OpenMAMA bridge for Qpid Proton C and we originally built
our API based on the pn_messenger interface. However I see that interface
is now marked for deprecation, so I'm looking for alternatives. I'd
appreciate any feedback on my assessment of the options available which are
listed below.

When I look at the alternative options available in
https://github.com/apache/qpid-proton/tree/master/examples/c, the options
seem to be between:

*Messenger:* Deprecated - so let's assume that's going away and not an
*Proactor: *Looks interesting, though no subscription level support and
looks to be experimental
*Reactor: *I think the proactor pattern looks like a better fit for us due
to its asyncronous nature, but this looks to be more stable? (or at least
not marked as experimental?) Again, light on subscription integration

So my initial feeling is to try moving to proactor. My main concern is
stability since it looks like it has already made an interface change since
0.17.0 (which expected while it's marked as experimental):
Is this something which is definitely going to be non-experimental soon or
is there chance the whole interface could get canned?

Which leaves the final question of how to solve the issue with addressing.
We have traditionally used one URI per topic to give the subscriber
isolation from other data sources (this is market data - large volumes,
large number of topics). This has proven very slow so maybe it's going
against the grain (it was configurable though in our application).

The new API looks like it would encourage more coarse addressing (e.g.
maybe one URI per exchange?), then defer to the payload to handle
addressing. Does that sound fair or are you supposed to be able to call
pn_proactor_connect many times (is it thread safe also)? I'm curious about
what sort of addressing patterns that others have used specifically for
market data or other use cases with a large number of topics and high


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