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, [email protected] 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: [email protected] For additional commands, e-mail: [email protected]
