Rafael - The trace was too long. The details are in PROTON-786. It looks like something is occurring on the Azure Event Hub side, so I don't know if there is a lingering issue w/ quid-proton as well.
On another note, when a disconnect happens, is it possible that "pn_messenger_status" could return PN_STATUS_UNKNOWN in addition to PN_STATUS_ABORT? Thanks -jim On Sat, Dec 20, 2014 at 4:03 AM, Rafael Schloming <r...@alum.mit.edu> wrote: > 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 >
