qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: qpid-proton, outgoing window, and message status == PN_STATUS_ABORT
Date Fri, 09 Jan 2015 13:32:07 GMT
Thanks for following up. Glad to hear you got to the bottom of the issue.

--Rafael

On Thu, Jan 8, 2015 at 6:21 PM, James Birdsall <jbird@microsoft.com> wrote:

> Followup on this: after much poking around to get a simplified repro, we
> isolated a bug in Service Bus. Proton seems to be behaving sanely under the
> circumstances.
>
> -----Original Message-----
> From: Rafael Schloming [mailto:rhs@alum.mit.edu]
> Sent: Saturday, December 20, 2014 11:20 AM
> To: users@qpid.apache.org
> Subject: Re: qpid-proton, outgoing window, and message status ==
> PN_STATUS_ABORT
>
> The frame below would suggest that something is going wrong on the Event
> Hub side of things, or at least that someone at microsoft would need to get
> involved in order to debug further. I do think there is at least one bug on
> the proton side here as this error message should really be displayed by
> default without requiring you to scrape through a large protocol trace to
> find it.
>
> --Rafael
>
> [0x100e01690]:0 <- @end(23) [error=@error(29)
> [condition=:"amqp:internal-error", description="An unexpected failure
> occurred. Applications should not attempt to handle this error. For
> diagnostic purposes, this English message is associated with the failure:
> Fragment link should forward dispose to incoming forwarding link.",
> info={:exception="Microsoft.ServiceBus.Common.AssertionFailedException: An
> unexpected failure occurred. Applications should not attempt to handle this
> error. For diagnostic purposes, this English message is associated with the
> failure: Fragment link should forward dispose to incoming forwarding
> link.\x0d\x0a   at Microsoft.ServiceBus.Common.Fx.AssertAndThrow(String
> description) in
>
> d:\bt\131432\private\source\ServiceBus\Clients\Microsoft.ServiceBus.Messaging\Common\Fx.cs:line
> 156\x0d\x0a   at
> Microsoft.ServiceBus.Messaging.Amqp.AmqpLink.OnDisposeDelivery(Delivery
> delivery) in
>
> d:\bt\131432\private\source\ServiceBus\Clients\Microsoft.ServiceBus.Messaging\Messaging\Amqp\AmqpLink.cs:line
> 346\x0d\x0a   at
>
> Microsoft.ServiceBus.Messaging.Amqp.AmqpSession.SessionChannel.OnReceiveDisposition(Disposition
> disposition) in
>
> d:\bt\131432\private\source\ServiceBus\Clients\Microsoft.ServiceBus.Messaging\Messaging\Amqp\AmqpSession.cs:line
> 641\x0d\x0a   at
>
> Microsoft.ServiceBus.Messaging.Amqp.AmqpSession.OnReceiveDisposition(Disposition
> disposition) in
>
> d:\bt\131432\private\source\ServiceBus\Clients\Microsoft.ServiceBus.Messaging\Messaging\Amqp\AmqpSession.cs:line
> 382\x0d\x0a   at
> Microsoft.ServiceBus.Messaging.Amqp.AmqpSession.ProcessFrame(Frame frame)
> in
> d:\bt\131432\private\source\ServiceBus\Clients\Microsoft.ServiceBus.Messaging\Messaging\Amqp\AmqpSession.cs:line
> 143"}]]
>
> On Sat, Dec 20, 2014 at 11:50 AM, Jim Spring <jmspring@gmail.com> wrote:
> >
> > 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