On Fri, Dec 19, 2014 at 7:50 PM, Jim Spring <jmspr...@gmail.com> wrote: > > Greetings - > > I've written a test application that all it does asynchronously send > messages to Azure EventHub using qpid proton. At the quid-proton level, I > have set the outgoing window (for tracking messages sent) at various sizes, > but let's say 1000. My sending makes sure that I keep this window > basically full. > > At the AMQP level, Event Hub negotiates an > outgoing-window/remote-incoming-window with an initial value of 300. And > is modified by flow frames. > > When in my loop, I go back to check on whether messages have finished being > sent or not, I usually check: > > pn_messanger_buffered(messenger, tracker) > > and > > pn_messenger_status(messenger, tracker) > > For the first 300 messages that go through successfully, > pn_messenger_buffer returns false, as expected and pn_messenger_status > returns PN_STATUS_PENDING. Once that 300 entity window is full, > pn_messenger_status starts returning PN_STATUS_ABORTED instead. > > I would assume that qpid-proton would be handling this under the hood? Am > I mistaken? >
The aborted status suggests the connection was shutdown for some reason. If you do an 'export PN_TRACE_FRM=1', you should be able to capture a protocol trace that might shed some light onto what is going on. It would be great if you could post that here (or in a JIRA if it is too long for the list). --Rafael
