qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.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:49:37 GMT
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
View raw message