Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id DF1B8200C2A for ; Wed, 1 Mar 2017 18:49:57 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id DDC6A160B70; Wed, 1 Mar 2017 17:49:57 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 32307160B56 for ; Wed, 1 Mar 2017 18:49:57 +0100 (CET) Received: (qmail 15826 invoked by uid 500); 1 Mar 2017 17:49:56 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 15814 invoked by uid 99); 1 Mar 2017 17:49:56 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Mar 2017 17:49:56 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 8E8691A7ADF for ; Wed, 1 Mar 2017 17:49:55 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -8.021 X-Spam-Level: X-Spam-Status: No, score=-8.021 tagged_above=-999 required=6.31 tests=[RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.999, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id GrdL2PNeJXJJ for ; Wed, 1 Mar 2017 17:49:54 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 5DA815F1EE for ; Wed, 1 Mar 2017 17:49:54 +0000 (UTC) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 475DF6AAC2 for ; Wed, 1 Mar 2017 17:49:24 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-24.phx2.redhat.com [10.3.116.24]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v21HnNk3026664 for ; Wed, 1 Mar 2017 12:49:23 -0500 Subject: Re: [proton-j] handling of link-credit To: users@qpid.apache.org References: <1488378679.5694.23.camel@gmail.com> <2c42870f-fb03-e26a-f046-5caf6e1d1609@redhat.com> <3aaeeef5-0edd-2e7a-83ba-8f33bef87663@redhat.com> From: Gordon Sim Organization: Red Hat UK Ltd, Registered in England and Wales under Company Registration No. 3798903, Directors: Michael Cunningham, Michael O'Neill, Eric Shander Message-ID: Date: Wed, 1 Mar 2017 17:49:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 01 Mar 2017 17:49:24 +0000 (UTC) archived-at: Wed, 01 Mar 2017 17:49:58 -0000 On 01/03/17 17:19, Robbie Gemmell wrote: > How did you know they had actually stopped or that it was then safe to > flow them new credit, just waiting for a while? > > If you flow new credit before the link is actually stopped you need to > cope with that fairly specifically in case they hadnt really stopped. > > There is scope for things to get out of whack otherwise, on both ends, > as they need to carefully handle the delivery-count and credit based > on what occurs and whether they have already exceeded the previous > allowances or not when the updates get sent/arrive. The link credit is an absolute value. Setting it to 0 then to some other value should be no different that e.g. setting it to 100, then resetting it to 200 before the first flow is known to have been processed by the sender. The latest value indicated by the receiver is the valid value. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org