qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Spring <jmspr...@gmail.com>
Subject Re: qpid-proton, outgoing window, and message status == PN_STATUS_ABORT
Date Sat, 20 Dec 2014 16:50:12 GMT
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 <rhs@alum.mit.edu> wrote:

> On Fri, Dec 19, 2014 at 7:50 PM, Jim Spring <jmspring@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message