qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: svn commit: r1642720 - in /qpid/trunk/qpid/cpp/src/qpid/messaging/amqp: AddressHelper.h ConnectionContext.cpp ReceiverContext.cpp ReceiverContext.h SessionContext.cpp SessionContext.h
Date Tue, 02 Dec 2014 19:57:40 GMT
>From a protocol perspective all transfers need to be settled.  Does the
broker support the "send settled" mode?  The sane thing for browsing
consumers would be to suggest to the broker that it should use
"snd-settle-mode" of settled.  The client would only need to
(automatically, behind the scenes) settle transfers if the broker opted not
to use that settlement mode.

-- Rob

On 2 December 2014 at 20:49, Alan Conway <aconway@redhat.com> wrote:

> On Tue, 2014-12-02 at 17:57 +0000, Gordon Sim wrote:
> > On 12/02/2014 05:38 PM, Gordon Sim wrote:
> > > On 12/01/2014 05:41 PM, aconway@apache.org wrote:
> > >> Author: aconway
> > >> Date: Mon Dec  1 17:41:09 2014
> > >> New Revision: 1642720
> > >>
> > >> URL: http://svn.apache.org/r1642720
> > >> Log:
> > >> QPID-6252: AMQP 1.0 browsing client generates large number of errors
> > >> on broker.
> > >>
> > >> The problem was that messages for browsing receivers were being
> > >> recorded on the
> > >> client SessionContext unacked list. This is incorrect since you don't
> ack
> > >> browsed messages.  They remained on the list after the browsing
> > >> receiver was
> > >> closed, and every subsequent call to acknowledge() on the client would
> > >> attempt
> > >> to ack these messages for a no-longer-existing link. Fix is to not
> record
> > >> browsed messages.
> > >
> > > I don't think this is right.
> > >
> > >  From the client's perspective, it should still be able to accept and
> > > settle deliveries, regardless of whether the broker will dequeue in
> > > response.
> > >
> > >  From the protocol perspective, deliveries must always get settled.
> > > Otherwise they need to be tracked (whether within proton or on the
> > > sending peer).
> > >
> > > As regards the original error, the spec says:
> > >
> > >      The disposition performative MAY refer to deliveries on
> > >      links that are no longer attached. As long as the links
> > >      have not been closed or detached with an error then the
> > >      deliveries are still “live” and the updated state MUST
> > >      be applied.
> > >
> > > It doesn't explicitly say what should happen if the link has been
> closed
> > > (not just detached), so its probably best to just ignore it on the
> > > broker (change the log level from error to info perhaps).
> > >
> > > The client should probably also settle all existing deliveries received
> > > on a link before closing it.
> >
> > Or perhaps at least remove the deliveries from the unacked list if their
> > associated link is closed.
> >
>
> The client definitely needs to do something with these deliveries,
> otherwise they accumulate on the session and you get longer and longer
> lists of bad acknowledgements as time goes on. I don't think anyone on
> the user interface side expects that they can/should ack messages from a
> browsing session, although I would think doing so should be a no-op not
> an error. Are you saying that the protocol requires it? From my reading
> the stuff about settlement only applies to "acquired transfers", which I
> took to exclude transfers from a link that is in COPY mode.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>

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