Re: C# DQPublisher Manager
Frank Quinn <fquinn.ni@...>
Hi Mathias, I just tried a scenario similar to what you described with mamapublisherc and mamasubscriberc and I can confirm that I can see the same issue. I'll have a look at what Qpid Proton have to offer in their latest releases to handle this scenario but I remember looking at this before and the problem revolves around the fact that most of the time, our calls to pn_messenger_put and pn_messenger_send don't actually return any error codes in the event of failure. If you look in the code, you'll see that we actually do error checking on those function calls but they don't return any failure.In fact I just checked and we raised this with the proton guys 2 years ago and they never responded so maybe we should chase that up :) http://qpid.2158936.n2.nabble.com/Detecting-and-capturing-underlying-problems-and-event-with-pn-messenger-td7595635.html To answer your more specific questions: - This is 100% qpid proton / MAMA - not your application's fault - The bridge doesn't even know, so we can't tell the application until we get a good answer from the qpid proton folks or find some new mechanism that has been added to handle this - This is certainly the case with MAMA but the underlying middleware implementation may not be so flippant as is the case here - all connections in AMQP implementations are connection oriented so they will always be a little more interactive by nature On a side note, have you tried our test Qpid Proton Broker implementation http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/feature-qpid-broker ? I expect it will make a lot of these sorts of problems go away and it will be a lot easier to configure (you don't need to specify a different port for each client, for example). Note that to use that branch, both clients and publishers will need to be compiled against it as the bridge's protocol messages have changed in that version.
On Mon, Jun 1, 2015 at 4:00 PM, Mathias Kim <Mathias.Kim@...> wrote: Hi guys,
|
|