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 Sat, 20 Dec 2014 19:20:05 GMT
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