qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: Alternatives to pn_messenger (QPID Proton C)
Date Wed, 03 May 2017 16:27:38 GMT
On 3 May 2017 at 08:55, Frank Quinn <fquinn.ni@gmail.com> wrote:
> 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
> option
> *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
> though.

The latter is where activity/attention is mostly going currently.

Its probably worth stating that Messenger fits at a slightly higher
level than the others. At a similar higher level would be the reactive
C++ API (http://qpid.apache.org/releases/qpid-proton-0.17.0/proton/cpp/api/tutorial.html),
built atop the C reactor but likely heading to being atop the

> 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):
> https://qpid.apache.org/releases/qpid-proton-0.17.0/proton/c/api/group__proactor.html#ga523ea983380a1566b3b1a7606d66422c.
> Is this something which is definitely going to be non-experimental soon or
> is there chance the whole interface could get canned?

It's going to be sticking around and is in the process of being
utilised in Qpid Dispatch to replace the routers existing IO handling
via https://issues.apache.org/jira/browse/DISPATCH-390 currently. I'll
let others who actually work on these bits speak to stability.

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

I wouldnt expect the API to encourage a particular form of addressing,
with you rather using what best suits your needs after taking into
consideration anything such as particular servers behaviours or use of
addressing to facilitate handling different sets of data in specific
ways, either in the servers or application code.

You can ultimately create as many or as few connections as you like,
and use as many or as few sender/receiver links over them, against as
many different addresses as suits your needs, save for certain fairly
large protocol level restrictions and any given servers abilities.

Somewhat related however, one thing the other APIs can expose that I'm
not sure if Messenger ever did, would be ability to use an 'anonymous
sender' link to send messages to difference addresses based on the
message 'to' address field, when supported by the server (such as the
Qpid brokers, Qpid Dispatch router, or ActiveMQ brokers).

Its also worth saying the address the AMQP message is sent to or is
received from is independent from the connection host details, even
though Messenger might have tied the two together somewhat in its
particular use of URIs.

> Cheers,
> Frank

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message