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 <[email protected]> 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:[email protected]] > Sent: Saturday, December 20, 2014 11:20 AM > To: [email protected] > 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 <[email protected]> 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 <[email protected]> > > wrote: > > > > > On Fri, Dec 19, 2014 at 7:50 PM, Jim Spring <[email protected]> > 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 > > > > > >
