On 3 May 2017 at 17:27, Robbie Gemmell <[email protected]> wrote: > On 3 May 2017 at 08:55, Frank Quinn <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
