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:30:00 GMT
On 3 May 2017 at 17:27, Robbie Gemmell <robbie.gemmell@gmail.com> wrote:
> 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.
>

Erm, no :)

I originally went to say former, but didn't since the list had
messegner at the top, and then somehow typed latter. Lets just say
*Proactor* :)


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


Mime
View raw message